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ABSTRACT 


This  thesis  shows  that  current  plans  for  Naval 
Aviation  Logistics  Command  Management  Information 
System  for  Organizational  Maintenance  Activities 
(NALCOMIS/OMA)  exclude  several  Important  data  collec¬ 
tion,  processing,  and  reporting  activities  which 
currently  take  place  at  squadron  maintenance  activi¬ 
ties.  The  Importance  of  these  local  activities  Is 
demonstrated  through  Interviews  with  NALCOMIS  Phase  II 
users  and  squadron  maintenance  managers.  It  Is  also 
shown  that,  although  local  In  nature,  these  activities 
are  vital  to  the  achievement  of  the  stated  objectives 
of  NALCOMIS. 
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I.  INTRODUCTION 


A.  BACKGROUND 

The  Naval  Aviation  Maintenance  Program  (NAMP), 
established  by  the  Chief  of  Naval  Operations  in  1959, 
"provides  an  Integrated  system  for  performing  aeronau¬ 
tical  equipment  maintenance  and  all  related  support 
functions."  [Ref.  l:p.  1]  It  Is  based  upon  the  concept 
that  maintenance  of  Naval  aircraft  be  performed  at 
three  different  levels  [Ref.  l:p.  3-1] : 

1.  Organizational  (O-level), 

2.  Intermediate  (I-level),  and 

3.  Depot  ( D-level ) . 

By  assigning  maintenance  tasks  to  different  levels 
according  to  complexity,  better  use  of  resources  Is 
possible.  A  routine  dally  repair  or  Inspection,  for 
example.  Is  best  accomplished  by  personnel  assigned  to 
the  organization,  or  squadron  In  possession  of  the 
aircraft  (O-level).  Maintenance  which  Is  beyond  the 
capabilities  of  the  squadron,  such  as  a  repair  requir¬ 
ing  special  equipment  or  training,  Is  handled  by  the 
Aircraft  Intermediate  Maintenance  Department  (I- 
level).  Even  more  complex  repairs,  such  as  major 
overhauls  and  rework,  are  performed  at  the  Depot-level. 


Due  to  a  growing  need  for  systems  of  "maintenance 


data  collection,  man-hour  accounting,  and  aircraft 

accounting,"  the  naval  aviation  Maintenance  and 

Material  Management  (AV-3M)  System  was  Introduced  as  a 

part  of  the  NAMP  In  1965  [Ref.  l:p.  l]s 

The  AV-3M  System  was  developed  to  modernize  the 
collection  of  data  at  the  local  level  and  to  assist 
In  the  summary  of  Information  for  reporting  purposes. 
Limited  capacity  of  both  computers  and  communication 
equipment  existed  In  support  of  AV-3M  sites. 
Inefficiencies  existed  within  AV-3M  for  data  collec¬ 
tion,  data  transfer  to  other  systems,  and  timeliness 
of  processing;  however,  the  Navy  was  moving  towards 
the  establishment  of  a  standardized  system  for  coding 
logistics  data  and  satisfying. .. reporting  require¬ 
ments.  [Ref.  2:p.  3] 

B.  NALCOMIS 

In  order  to  alleviate  the  problems  associated  with 

the  manual  data  collection  and  reporting  methods  of  AV- 

3M,  the  Naval  Aviation  Logistics  Command  Management 

Information  System  (NALCOMIS)  project  was  established 

In  1974.  NALCOMIS  was  conceived  as 

a  modern  computer  system  to  provide  timely  and 
accurate  aircraft  maintenance,  operations,  and 
logistics  data.  These  data  are  to  be  used  in  support 
of  the  day-to-day  maintenance  and  supply  activities, 
as  well  as  to  communicate  key  summary  Information  [up 
the  chain  of  command]  for  management  analysis.  [Ref. 
3:p.  3] 

"There  are  four  primary  objectives  of  NALCOMIS, 
each  of  which  has  a  major  Impact  on  the  mission 
capability  and  overall  personnel  effectiveness"  at  the 
Organizational  and  Intermediate  Maintenance  Activities 


and  the  supply  centers  which  support  them  [Ref.  2:p. 

4].  These  four  objectives  are: 

1)  Improved  Aircraft  Mission  Capability. 

2)  Improved  Aircraft  Maintenance  and  Supply  Support. 

3)  Improved  Reporting  to  Satisfy  Navy  and  Department 

of  Defense  Program  Requirements. 

4)  Modernized  Management  Support. 

It  is  estimated  that  NALCOMIS  will  require  approxi¬ 
mately  three  million  lines  of  code  and  will  consist  of 
over  twenty-eight  hundred  programs  [Ref.  4].  Due  to 
the  size  of  NALCOMIS  and  the  complexity  of  the  func¬ 
tions  it  is  to  perform,  development  of  NALCOMIS  and 
release  to  the  fleet  is  being  accomplished  in  three 
phases  [Ref.  5:p.  3-1]. 

Phase  I  serves  as  an  interim  system  in  support  of 
Intermediate  Maintenance  Activities  and  Supply  Support 
Centers  until  NALCOMIS  development  is  completed. 

"Phase  I  provides  the  aviation  maintenance  and  material 
managers  with  a  long  awaited  automated  repalrables 
management  tool."  [Ref.  6]  Also  referred  to  as 
NALCOMIS  Repalrables  Management  Module  (NRMM),  Phase  I 
has  already  been  Implemented  at  Naval  Air  Stations, 
Marine  Aircraft  Groups  (MAGs),  and  Aircraft  Intermedi¬ 
ate  Maintenance  Departments  (AIMDs)  and  Supply  Support 
Centers  (SSCs)  aboard  aircraft  carriers. 

Phase  II  provides  automated  data  collection  and  on¬ 
line  data  processing  capabilities  to  AIMDs  and  SSCs. 


I'i 


"Functional  design  was  completed  In  September  1985  and 
software  design  and  development  commenced  In  August 
1985."  [Ref.  6]  A  prototype  was  Installed  at  MAG-14, 
MCAS  Cherry  Point,  in  October  1986.  Implementation  of 
Phase  II  at  selected  AIMD/SSCs  is  currently  in  prog¬ 
ress  . 

Phase  III  will  automate  Organizational  Maintenance 
Activities  (OMAs)  much  as  Phase  II  is  automating  AIMDs. 
The  Initial  design  for  Phase  III,  also  called 
NALCOMIS/OMA,  was  completed  In  September  1986  and 
development  was  begun  the  following  month.  By  July 
1987,  however,  while  NALCOMIS  Phases  I  and  II  continued 
In  various  stages  of  Implementation  and  testing, 
development  of  NALCOMIS/OMA  was  suspended  due  to  end- 
of-fi seal -year  budgetary  constraints. 

Also  a  part  of  Phase  III,  NALCOMIS  for  Detachments 
Subsystem  (NDS)  will  provide  smaller  aviation  detach¬ 
ments  (e.g. ,  LAMPS  and  VERTREP  detachments)  with 
management  support  and  automation  capabilities.  NDS, 
currently  In  the  early  stages  of  design,  will  be  a 
simplified  version  of  NALCOMIS/OMA. 

The  Navy  Management  Systems  Support  Office,  the 
designated  central  design  activity  for  NALCOMIS,  has 
expressed  uncertainty  as  to  the  future  of  Phase  III 
development.  Should  NALCOMIS/OMA,  as  currently 
defined,  be  further  developed  and  tested,  or  should 
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NDS,  a  more  streamlined  version,  become  a  basic 
building  block  and  expanded  as  necessary  to  meet  the 
requirements  of  larger  maintenance  activities?  Or 
should  some  third  alternative  should  be  considered? 

C.  THESIS  OBJECTIVES 

The  objective  of  this  thesis  is  to  show  that 
current  plans  for  NALCOMIS/OMA  exclude  several  impor¬ 
tant  data  collection,  processing,  and  reporting 
activities  ’which  currently  take  place  at  squadron 
maintenance  activities.  The  Importance  of  these  local 
activities  will  be  demonstrated  through  interviews  with 
users  of  the  NALCOMIS  Phase  II  system  and  squadron 
maintenance  managers.  It  will  also  be  shown  that, 
although  local  in  nature,  these  activities  are  vital  to 
the  achievement  of  the  stated  objectives  of  NALCOMIS. 

Several  of  the  key  development  issues  Involved  in 
automating  the  OMA  will  also  be  examined: 

1 )  How  can  NALCOMIS  provide  management  support  to 
squadron  maintenance  managers? 

2)  What  can  NALCOMIS  do  at  the  squadron  level  to 
Improve  mission  capability? 

3)  Should  NALCOMIS/OMA  be  further  developed  or  should 
NDS  be  expanded  to  meet  the  needs  of  the  OMA? 

D.  SCOPE,  LIMITATIONS,  AND  ASSUMPTIONS 

While  NALCOMIS  has  been  divided  into  phases  for 
development  and  implementation,  each  phase  in  Itself 
represents  a  tremendously  complex  system.  Therefore, 
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the  Intent  of  this  thesis  Is  not  to  provide  detailed 


solutions  to  the  technical  Issues  which  remain.  It  Is. 
rather,  an  attempt  to  examine  the  big  picture  of 
NALCOMIS/OMA  from  both  the  computer  systems  management 
and  organizational  maintenance  perspectives. 

Due  to  time  and  travel  constraints,  research  on 
organizational  maintenance  activities  was  conducted  at 
one  geographical  site.  Because  NAMP  procedures  apply 
universally  to  Naval  Aviation  activities.  It  was  not 
anticipated  that  this  would  be  a  limiting  factor  In  the 
study.  It  was  discovered,  however,  that  while  NALCOMIS 
Is  designed  to  support  the  NAMP,  local  procedures  are 
also  Important.  They  are.  In  fact,  vital  to  meeting 
the  objectives  of  NALCOMIS.  Therefore,  conducting 
research  at  only  one  site  did  become  a  limiting  factor 
In  the  study. 

E.  RESEARCH  APPROACH 

Numerous  telephone  conversations  (commencing  In 
July  1987)  with  the  Commanding  Officer  and  other  Navy 
Management  and  Systems  Support  Office  (NAVMASSO) 
personnel  revealed  that  some  uncertainties  regarding 
NALCOMIS/OMA  still  existed.  Since  development  of  this 
particular  phase  of  NALCOMIS  was  temporarily  suspended 
due  to  fiscal  constraints.  It  appeared  to  be  a  good 
time  to  examine  some  of  these  uncertainties. 


After  conducting  an  extensive  search  of  publica¬ 
tions  dealing  with  NALCOMIS,  It  was  determined  that 
personal  Interviews  would  be  required  In  order  to 
establish: 

1)  Past  and  present  management  philosophies  which  led 
to  the  current  plans  for  NALCOMIS/ OMA, 

2)  The  major  concerns  of  those  who  had  used  Phase  II 
and  NALCOMIS/OMA  prototype  systems*  and 

3)  Potential  concerns  of  future  users  of  the  system. 

The  first  objective  was  met  through  a  visit  with 

NAVMASSO  personnel  In  Norfolk*  Virginia.  Interviews 
were  conducted  with  key  Individuals  who  had  been 
Involved  with  Phase  III  during  Its  earlier  development. 
Additional  Information  was  obtained  during  a  visit  to 
former  PMA-270  Maintenance  Officer,  CDR  Bob  Jaurnlg. 

Phase  II  users  (and  those  with  experience  on  a 
Phase  III  partial  prototype  at  Arthur  Andersen  and 
Company)*  each  having  a  great  deal  of  experience  as 
aviation  maintenance  managers,  provided  valuable 
Insight  Into  current  and  anticipated  problems  with  the 
system.  The  author  also  gained  some  hands-on  experi¬ 
ence  with  the  Phase  II  system. 

Interviews  were  conducted  at  a  typical  organiza¬ 
tional  maintenance  activity  at  Naval  Air  Station 
Lemoore,  California*  In  December  1987,  to  further 
determine  potential  user  concerns.  These  interviews 
were  not  intended  to  determine  how  future  users  would 
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react  to  using  a  computer  system,  but  rather  to 
document  In  detail  some  of  the  current  procedures  used 
In  aviation  maintenance.  Because  some  procedures  are 
local  and  therefore  vary  from  one  organization  to  the 
next,  such  a  local  study  was  felt  necessary  in  order  to 
determine  what  sort  of  flexibility  NALCOMIS/OMA  should 
possess . 


F.  ORGANIZATION  OF  THE  THESIS 

The  organization  of  the  *»*.  saining  chapters  of  this 
thesis  Is  as  follows: 

II.  THE  ORGANIZATIONAL  MAINTENANCE  ACTIVITY: 

Provides  a  brief  overview  of  the  Organizational 
Maintenance  Activity  and  those  Individuals  who  will 
be  using  NALCOMIS/OMA. 

III.  NALCOMIS/OMA:  Introduces  NALCOMIS/OMA  and  NDS. 

It  also  Includes  a  short  discussion  of  some  of  the 
hardware  and  software  constraints  placed  on  the 
developers  of  NALCOMIS. 

IV.  DEVELOPMENT  DECISIONS:  Some  of  the  critical 
decisions  which  must  be  made  by  those  managing  the 
development  of  NALCOMIS/OMA  are  discussed.  Current 
plans  for  NALCOMIS/OMA  are  compared  with  the  overall 
objectives  of  the  project.  Also,  the  Implications  of 
expanding  NDS  to  meet  the  Information  needs  of  the 
OMA  Is  examined. 

V.  USER  CONCERNS:  Contains  the  results  of  interviews 
conducted  with  maintenance  managers  who  have  gained 
experience  with  the  NALCOMIS  Phase  II  system  and  the 
partial  prototype  which  exists  at  Arthur  Andersen  and 
Company . 

VI.  NAMP  PROCEDURES:  Introduces  the  VIDS/MAF--the 
tool  used  to  collect  most  of  the  maintenance  data  in 
the  squadron.  The  flow  of  the  VIDS/MAF  Is  traced 
through  the  maintenance  organization  and  some  of  the 
potential  benefits  of  automating  the  MAF  are  Identi¬ 
fied. 


VII.  LOCAL  PROCEDURES:  Several  local  management  tools 
used  by  maintenance  managers  are  Identified.  The 
Importance  of  these  tools  Is  related  to  user’s 
(bottom-level  management's)  acceptance  of 
NALCOMIS/OMA. 

VIII.  ESTABLISHING  AN  EFFECTIVE  INFORMATION  SYSTEM 
FOR  THE  OMA:  The  attributes  of  an  effective  Informa¬ 
tion  system  are  applied  to  the  results  of  the 
research  contained  In  chapters  IV  through  VII.  By  so 
doing,  the  Importance  of  providing  the  OMA  with 
local,  pertinent,  and  flexible  reporting  capabilities 
Is  established. 

IX.  CONCLUSIONS  AND  RECOMMENDATIONS:  Presents  the 
conclusions  of  the  study  and  makes  recommendations 
for  future  actions  and  further  research. 


THE  ORGANIZATIONAL  MAINTENANCE  ACTIVITY 


While  this  thesis  assumes  that  most  readers  have  a 
fair  knowledge  of  the  organizational  maintenance 
activity  (OMA)  and  Its  functions,  a  brief  overview 
should  provide  unfamiliar  readers  with  some  under¬ 
standing  as  well.  Although  somewhat  simplified,  such 
an  overview  should  also  serve  to  Identify  those 
Individuals  at  different  levels  In  the  organization 
that  are  referred  to  as  maintenance  managers  In  this 
thesis . 

A.  SQUADRON  ORGANIZATION 

The  naval  aviation  squadron  Is  composed  of  four 
departments:  Administrative,  Operations,  Safety,  and 

Maintenance.  Each  of  the  departments  Is  typically 
headed  by  an  aviator  who  Is  a  senior  Lieutenant 
Commander  or  Junior  Commander.  These  officers  periodi¬ 
cally  rotate  from  one  department  head  billet  to  another 
In  order  to  gain  the  experience  necessary  to  later 
become  a  Commanding  Officer.  Therefore,  the  Mainte¬ 
nance  Officer,  for  Instance,  Is  Involved  not  only  with 
the  maintenance  activities  of  the  squadron  but  also 
with  flying  and  other  related  duties  as  well.  For  this 
reason,  he  Is  surrounded  by  Individuals  who  are  devoted 


primarily  to  maintenance — so  called  maintenance 
professionals . 

The  organization  of  the  Maintenance  Department  Is 
shown  In  Figure  1  [Ref.  7:p.  3-3].  As  the  lower 
portion  of  the  chart  Indicates,  the  department  Is 
divided  Into  divisions.  Each  division.  In  turn,  is 
composed  of  branches.  The  Avionics/Armament  Division, 
for  example,  consists  of  those  branches  which  are 
concerned  with  the  aircraft's  electrical,  electronic, 
and  associated  weapons  systems.  It  Is  these  branches 
which  will  commonly  be  referred  to  as  work  centers. 

Such  a  grouping  of  branches  tinder  common  divisions  has 
evolved  In  order  to  assure  efficient  organization  of 
skilled  personnel  and  proper  assignment  of  maintenance 
tasks . 

B.  RESPONSIBILITIES 

The  Maintenance  Officer  (MO)  Is  responsible  to  the 
Commanding  Officer  for  all  matters  concerning  the 
department.  The  Assistant  Maintenance  Officer  (AMO), 
as  the  name  Implies,  assists  the  MO  In  running  the 
department.  Usually  an  officer  with  no  flying  duties 
(ground  officer)  and  designated  a  full-time  maintenance 
manager,  he  has  held  various  positions  within  the 
department  In  the  past.  Included  among  his  responsi¬ 
bilities  are  administrative  duties,  liaison  with  other 
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departments,  assignment  of  maintenance  personnel,  and 
training  [Ref.  7:p.  4-7]. 

Quality  Assurance/Analysis  (QA/A),  headed  by  the 
Quality  Assurance  Officer,  Is  responsible  for  the 
overall  quality  of  maintenance  within  the  organization. 
Included  among  those  programs  assigned  to  QA/A  are  QA 
audits.  Central  Technical  Publications  Library,  ground 
safety,  and  data  trend  analysis  [Ref.  7:p.  5-11]. 

Several  managers  assist  the  QA  Officer  In  his 
duties.  The  QA  Chief  Petty  Officer  (CPO),  a  senior 
enlisted  Individual  with  extensive  knowledge  of 
aircraft  maintenance,  is  the  QA  Officer’s  right-hand 
man  with  respect  to  QA  matters.  Quality  Assurance 
representatives,  in  addition  to  providing  technical 
guidance  In  their  particular  areas  of  expertise,  assist 
in  the  preparation  of  department  maintenance  Instruc¬ 
tions,  certification  of  production  (work  center) 
personnel,  and  developing  checklists  for  auditing  work 
centers  and  specific  maintenance  programs  [Ref.  7:p.  5- 
8].  The  QA  Analyst  provides  management  with  the  data 
necessary  to  make  decisions  with  regard  to  aircraft  and 
equipment  "condition,  readiness,  and  utilization." 

[Ref.  7 : p .  5-6]  Finally,  the  Central  Technical  Publica¬ 
tions  Librarian  maintains  those  publications  pertinent 
to  that  particular  maintenance  activity. 


Maintenance  Administration  provides  clerical  and 
administrative  services  for  the  department.  Such 
services  Include  maintaining  reports  and  records  for 
the  department  as  veil  as  preparing  correspondence 
which  requires  executive  action  or  special  attention  by 
the  MO  or  higher  authority  [Ref.  7:p.  4-11]. 

Maintenance  Control,  as  its  name  implies,  is  at  the 
heart  of  the  maintenance  effort.  Headed  by  the 
Maintenance/Material  Control  Officer,  it  is  the  central 
point  of  coordination  between  work  centers.  By  keeping 
the  overall  picture  of  aircraft  maintenance  in  mind, 
decisions  are  made  about  the  priority  of  each  Job  and 
which  resources  to  apply  to  those  Jobs.  A  Maintenance 
CPO ,  stationed  at  the  Maintenance  Control  desk  during 
each  work  shift,  is  the  individual  primarily  charged 
with  making  those  decisions. 

Material  Control  consists  of  aviation  storekeepers 
who  act  as  points  of  contact  between  department 
personnel  and  the  supply  activity  that  supports  the 
squadron.  Trained  in  supply  requisition  procedures, 
they  order  parts  and  materials  in  support  of  the 
maintenance  effort  and  provide  department  managers  with 
the  status  of  those  requisitions.  Material  Control 
also  maintains  the  squadron’s  Operating  Target  (OPTAR) 
account  which  consists  of  those  funds  from  which  the 


squadron  buys  aviation  fuels,  flight  clothing  and  other 
administrative  supplies. 

The  Individual  Material  Readiness  List  (IMRL)  is 
also  managed  by  Material  Control  personnel.  The  IMRL 
manager  maintains  transfer,  receipt,  and  custody 
records  of  those  support  equipment  items  which  are  in 
the  squadron's  possession. 

Each  division  is  headed  by  a  Division  Officer  and  a 
Division  CPO .  Depending  on  the  number  of  officers  and 
CPOs  available  in  the  squadron,  some  branches  may  also 
contain  a  Branch  Officer  and/or  CPO. 

Management  of  the  hour-by-hour  tasks  assigned  to 

each  work  center  is  done  by  the  work  center  supervisor. 

His  importance  cannot  be  overemphasized: 

If  successful  accomplishment  of  assigned  tasks  could 
be  attributed  to  any  one  group  of  personnel,  it  would 
be  the  work  center  supervisors.  Diligent  supervision 
at  the  work  center  level  includes  rigidly  adhering 
to. . .procedures  and  policies.  To  ensure  the  accom¬ 
plishment  of  all  assigned  work,  maximum  efficiency 
must  be  obtained  and  maintained  in  the  use  of 
manpower,  material,  and  facilities.  [Ref.  7:p.  9-1] 

C.  EXCHANGE  OF  INFORMATION 

While  Figure  1  [Ref.  7:p.  3-3]  shows  the  hierarchi¬ 
cal  composition  of  the  Maintenance  Department,  it  does 
not  show  the  constant  exchange  of  information  that 
takes  place  between  the  various  components  making  up 
the  department.  Because  aviation  maintenance  is  a 
dynamic  activity  filled  with  uncertainty,  timely 


communication  among  those  various  components  is  the  key 
to  smooth  and  efficient  operations.  As  will  be  shown 
later,  such  communication  currently  occurs  In  the  OMA 
and  must  occur  In  any  future  system  If  it  Is  to  prove 
useful  to  maintenance  managers. 

In  addition  to  Information  exchanges  within  the 
Maintenance  Department  Itself,  there  also  exist 
exchanges  between  Maintenance  and  other  departments  as 
well.  Most  pertinent  to  this  thesis  are  the  exchanges 
which  take  place  between  the  Maintenance  and  Operations 
Departments.  Operations,  In  Its  planning  and  schedul¬ 
ing  of  flights,  must  be  aware  of  the  maintenance 
situation.  It  must,  for  Instance,  know  how  many 
aircraft  are  available  to  fly  and  what,  if  any, 
aircraft  subsystem  limitations  exist. 

Maintenance  must  likewise  be  aware  of  the  needs  and 
requirements  of  operations.  It  must  know  not  only  how 
many  aircraft  are  needed,  but  also  what  sort  of 
aircraft  subsystems  are  required  to  fulfill  the 
mission,  how  much  fuel  Is  required,  what  weapons  are 
needed,  etc.  Because  the  maintenance  situation  Is 
always  changing,  both  departments  must  remain  in 
constant  communication  with  one  another. 

The  OMA  also  depends  on  communication  with  other 
organizations.  Maintenance  personnel  must  be  able  to 
find  out  when  they  can  expect  replacement  parts  which 
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have  been  ordered  from  the  Supply  Support  Center  (SSC). 
Also,  the  OMA  must  be  able  to  communicate  with  the 
local  Aircraft  Intermediate  Maintenance  Department 
(AIMD)  so  that  It  knows  the  status  of  aircraft  com¬ 
ponents  which  are  being  repaired  at  the  AIMD. 

The  exchanges  of  maintenance  and  supply  Information 
within  the  aviation  squadron,  and  among  the  squadron 
and  the  AIMD/SSC,  should  be  Improved  by  NALCOMIS/OMA . 
Communication  among  the  activities  Involved  In  aviation 
maintenance  should  become  faster  and  more  efficient 
through  the  use  of  automated  data  collection  and 
processing.  NALCOMIS/OMA  and  its  functions  will  be 
discussed  In  the  following  chapter. 


S 


*  V  V  V  ' 


III.  NALCOMIS/OMA 


A.  GENERAL  SYSTEM  DESCRIPTION 

NALCOMIS/OMA  Is  seen  as  a  means  of  achieving 
Improved  mission  capability  at  the  squadron  level.  In 
achieving  this  end.  It  is  proposed  by  the  Navy  Manage¬ 
ment  Systems  Support  Office  that  NALCOMIS  will  [Ref. 
3:p.  4] : 

1 )  Support  "a  thorough  inspection  and  approval 
process... to  verify  repair  completion  and  determine 
material  readiness." 

2)  Assist  In  "establishing  a  maintenance  schedule  by 
considering  the  priorities  of  available  resources 
Including  skills,  worker  hours,  material,  and  support 
equipment . " 

3)  Provide  an  information  reporting  capability. 

4)  Provide  for  the  "tracking  and  controlling  of 
resources . " 

5)  Reduce  administrative  burden  within  the  OMA. 
NALCOMIS/OMA  Is  to  provide  such  capabilities  to 
activities  both  afloat  and  ashore. 

The  primary  objectives  of  NALCOMIS  are  described  In 

the  system’s  Functional  Description  [Ref.  3:p.  3]: 

1 )  Improved  Aircraft  Mission  Capability.  Through 
more  accurate  and  timely  processing  of  data,  the 
organizational  levels  will  be  able  to  better  manage 
and  take  action  on  the  Information  provided  by  the 
system.  Delays  due  to  awaiting  maintenance  (AWM)  or 
awaiting  parts  (AWP)  will  be  reduced.  This  will  in 
turn  greatly  improve  the  aircraft  availability  and 
overall  maintenance  capability. 
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2 )  Improved  Aircraft  Maintenance  and  Supply  Support. 
Through  more  accurate  and  timely  Information, 
maintenance  and  supply  personnel  will  be  able  to 
improve  their  overall  productivity  and  available  man¬ 
hours.  The  component  turnaround  time  will  be  reduced 
as  a  result  of  faster  supply  response  time  and  less 
time  spent  on  ADP  oriented  activities.  NALCOMIS  has 
been  designed  to  follow  NAMP  guidelines  for  both 
supply  and  maintenance  functions. 

3 )  Improved  Reporting  to  Satisfy  Navy  and  Department 
of  Defense  (POD)  Program  Requirements.  The  entire 


NALCOMIS  system  will  provide  interfaces  which  are 
straightforward  and  automated,  requiring  little 
manual  intervention.  Data  sent  [to]...AV-3M  and 
other  naval  aviation  logistics  support  systems  are 
maintained  within  NALCOMIS  to  provide  timely, 
accurate,  and  complete  data  in  the  format  acceptable 
by  each  system.  The  OMA  system  will  provide  inter¬ 
faces  to  AV-3M. 

4)  Modernized  Management  Support.  The  system  will 
provide  comprehensive  support  of  aviation  maintenance 
and  supply  functions  at  the  organizational  and 
intermediate  levels,  both  ashore  and  afloat.  The  on¬ 
line,  interactive  features  of  NALCOMIS  will  provide 
the  needed  response  time  to  support  dally  activities 
and  provide  timely  Information  to  local  managers  and 
[other  information]  systems.  Common  Inputs  and 
outputs  also  have  been  designed  throughout  the  system 
to  facilitate  training  activities  and  ease  of  use.  A 
common  data  base  will  ensure  data  control  and  overall 
accuracy  and  validity  of  information. 

"Standardization  of  Automated  Data  Processing  (ADP) 
hardware  and  system  software  was  achieved  under  the 
Shipboard  Non-tactlcal  ADP  Program  (SNAP)  I,  Phase  2." 
[Ref.  2:p.  3]  The  SNAP  I  minicomputer  hardware 
targeted  for  NALCOMIS/OMA  consists  of  [Ref.  3:p.  21]: 

1)  The  central  processing  unit... a  HIS  [Honeywell 
Information  Systems]  DPS  6/74  processor  with  one 
megaword  (MV)  of  memory. 

2)  Storage  media  for  the  nondeployable 
configuration. .. four  67  megabyte  (MB)  disk  drives 
(268  MB  of  total  disk  storage).  The  deployable 


storage  media... six  50.1  MB  Winchester  disk  drives 
(300.6  MB  total  disk  storage). 

3)  Up  to  two  300  lines  per  minute  (LPM)  printers  and 
up  to  three  ASPI-34  form  printers. 

4)  One  console  terminal,  fifteen  work  station 
terminals,  sixteen  80  characters  per  second  (CPS) 
screen  printers  (one  attached  to  each  terminal)  and 
two  eight-inch  diskette  handlers. 

A  similar  hardware  environment  exists  at  the  IMA/SSC 

(NALCOMIS  Phase  II)  level. 

NALCOMIS/OMA  Is  being  designed  such  that  It  will 
provide  on-line,  real  time  capabilities  22  hours  per 
day  with  the  remaining  two  hours  reserved  for  batch  and 
backup  processing: 

On-line  functions  are  performed  by  user  personnel 
operating  keyboard  video  display  terminals  (KVDTs) 
located  In  their  assigned  sections  or  work  centers. 
Cn-llne  functions  allow  the  Immediate  entry,  update, 
or  retrieval  of  Information.  These  on-line  functions 
are  controlled  by  an  on-line  monitor.  Batch  process¬ 
ing  functions,  which  are  not  controlled  by  an  on-line 
monitor,  are  either  queued  for  Immediate  processing 
or  are  performed  at  scheduled  periods  each  day 
depending  upon  the  level  of  system  resources  required 
to  complete  the  batch  processing  function.  Hardcopy 
notices,  reports,  report  extracts,  data  base  purge 
processing,  and  data  base  reorganizations  are 
examples  of  batch  processing  functions  [Ref.  8:p.  5]. 


As  developed  thus  far,  NALCOMIS  for  OMAs  Is  divided 
Into  10  subsystems  [Ref.  3:pp.  8-10]: 

1)  Data  Base  Maintenance  Subsystem.  This  subsystem 
establishes  and  maintains  the  nonvolatile  data  within 
NALCOMIS  and  performs  the  necessary  local  data  base 
support  functions  for  all  subsystems. 

2)  Flight  Activity  Subsystem.  The  major  functions 
associated  with  this  subsystem  Include  the  recording 
of  aircraft  flight  utilization  data  on  the  Naval 
Aircraft  Flight  Record. ..( 1 . e . ,  the  "Yellow  Sheet"). 


3)  Maintenance  Activity  Subsystem.  This  subsystem 
Includes  those  functions  and  processes  required  to 
maintain  aircraft,  engines,  and  equipment.  [It  also] 
provides  the  capability  to  perform  fully  automated 
processing  of  the  Visual  Information  Display 
System/Maintenance  Action  Form  (VIDS/MAF)  in  accor¬ 
dance  with  policies  described  In  the  NAMP. 

4)  Configuration  Status  Accounting  Subsystem.  This 
subsystem  provides  the  capability  to  establish  and 
maintain  the  configuration  profile  of  aircraft, 
aircraft  engines,  aircraft  components,  engine  modules 
and  components,  support  equipment,  and  support 
equipment  components. 

5)  Personnel  Management  Subsystem.  This  subsystem 
includes  the  functions  necessary  to  collect  and 
maintain  specific  personnel  data  for  both  military 
and  civilian  personnel  assigned  to  an  organization. 

6)  Asset  Management  Subsystem.  This  subsystem 
addresses  the  management  of  aircraft  and  equipment 
assigned  to  an  organization.  All  aircraft  and 
specific  equipment  are  Inventoried  and  the  readiness 
status  determined  and  recorded. 

7)  Local /Upline  Reporting  Subsystem.  This  subsystem 
provides  the  capability  to  capture  Information 
accumulated  by  the  other  subsystems,  combines  and 
consolidates  that  data  Into  detail  and  summary  level 
management  reports,  and  extracts  the  data  base 
Information  necessary  to  satisfy  the. .. reporting 
requirements  of  the  NAMP. 

8)  System  Support  Subsystem.  Communication  between 
organizations  Is  also  handled  by  this  subsystem 
through  the  maintenance  of  on-line  messages  to  the 
appropriate  organization. 

9)  Data  Offload/Onload  Subsystem.  This  subsystem 
provides  for  the  of f load/ onload  of  data  associated 
with  the  transfer/arrival  of  aircraft,  equipment  and 
personnel . 


10)  Technical  Publications  Subsystem.  This  subsystem 
tracks  the  location  of  technical  publications  owned 
by  the  organization  and  provides  on-line  access  to 
that  Information. 


Each  of  the  subsystems  In  NALCOMIS/OMA  consists  of 
on-line  screens  and  conversations.  "An  on-line  screen 
is  a  formatted  display  of  input  forms  or  output  data. 

An  on-line  conversation  is  the  collection  of  screens 
required  to  accomplish  a  single  business  function. " 
[Ref.  8:p.  3] 

Each  subsystem  offers  several  other  output  products 
to  the  user.  Electronic  messages  may  be  sent  from  one 
terminal  to  another.  Printed  output,  in  the  form  of 
notices  and  reports,  is  also  available.  nA  notice  is  a 
document  printed  as  a  result  of  an  on-line  transaction 
that  requires  immediate  follow-up  action.  A  report  is 
a  multi-page  document  containing  information  for  local 
and  [higher  level]  management."  [Ref.  8:p.  3]. 

Each  of  the  conversations  vlthln  NALCOMIS  follows 
one  of  five  conversation  categories  [Ref.  3:p.  14]: 

1)  Data  Entry.  This  conversation  is  used  to  enter 
data  on  either  a  single  screen  or  a  series  of 
screens.  Depending  on  the  conversation,  a  mailbox 
message,  hardcopy  notices,  or  Interface  record  may  be 
generated.  Examples  of  data  entry  conversations  are 
the  creation  of  MAFs,  personnel  records,  and  aircraft 
records  within  NALCOMIS. 

2)  Update/Delete .  This  conversation  [is  used]... to 
select  the  desired  record  for  processing.  Depending 
on  the  conversation,  a  mailbox  message,  hardcopy 
notice,  or  Interface  may  be  generated.  Examples  of 
an  update/delete  conversation  are  to  update  a  MAF  Job 
status  or  to  delete  a  component  configuration  record. 

3)  Display.  This  conversation  displays  a  single 
record... No  mailbox  messages,  hardcopy  notices,  or 
Interfaces  are  generated.  Example  conversations  are 
to  display  a  specifically  identified  MAF,  material 
requirement,  or  personnel  record. 
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4)  List  Display.  This  conversation  displays  a  list 
of  specific  records... No  mailbox  messages,  hardcopy 
notices,  or  Interfaces  are  generated.  Example 
conversations  are  to  display  information  for  all  open 
MAFs  for  a  work  center,  list  all  personnel  with  a 
specific  SMQ  [Special  Maintenance  Qualification],  or 
list  all  material  requirements  for  a  MAF. 

5)  Batch  Report  Request.  This  conversation  requires 
entry  of  the  report  identification  and  data  selection 
criteria,  if  required.  The  report  is  then  produced 
during  a  subsequent  process.  The  report  request  will 
be  used  to  notify  the  system  operator  to  produce  the 
proper  report.  In  addition  to  requested  reports,  the 
system  will  automatically  produce  standard  batch 
reports  routinely  printed  on  a  dally,  weekly, 
monthly,  and  quarterly  basis. 

Qualified  users  will  be  allowed  access  to  the 
system  during  sign-on  via  unique  passwords.  Access  to 
specific  conversations  will  be  limited  to  those 
individuals  possessing  an  appropriate  Special  Mainte¬ 
nance  Qualification  code.  Classified  data  will  not  be 
processed  by  NALCOMIS/OMA. 

Various  failure  contingencies  are  required  for 
NALCOMIS/OMA.  Squadrons  must  be  provided  with  alterna¬ 
tive  methods  for  data  collection  and  processing  in  case 
the  system  unexpectedly  goes  down.  Such  alternatives 
might  Include  processing  on  another  computer  system  or 
even  reverting  to  manual  methods  (paper  MAFs). 

Although  a  detailed  analysis  of  contingency  procedures 
is  beyond  the  scope  of  this  thesis,  some  discussion  is 
Included. 

NALCOMIS/OMA  will  be  required  to  communicate  with 
other  systems.  One  such  interface  will  allow  the  AV-3M 
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system  to  "process  summary  information  to  analyze  the 
performance  of  NALCOMIS/OMA  organizations."  [Sef.  8:p. 
27]  In  addition,  similar  data  reporting  to  Aircraft 
Controlling  Custodians  and  Type  Commanders  will  be 
supported.  Other  NALCOMIS  sites,  such  as  IMAs  and 
Supply  Support  Centers  will  also  be  capable  of  inter¬ 
facing  with  the  OMA. 

The  NALCOMIS  program  manager  is  Naval  Air  Systems 
Command  Headquarters  (Project  Manager  Air-270)  and  the 
Central  Design  Agency  is  the  Navy  Management  Systems 
Support  Office  (NAVMASSO)  [Ref.  l:p.  8-3].  NAVMASSO  is 
responsible  for  design,  development,  implementation, 
and  life  cycle  support  for  NALCOMIS.  The  NALCOMIS/OMA 
contractor  is  Arthur  Andersen  and  Company. 

B.  NALCOMIS  FOR  DETACHMENTS  SUBSYSTEM— NDS 

For  aviation  detachments  serving  aboard  ships  which 
are  not  supported  by  IMA/SSCs  (i.e.,  LAMPS  and  VERTREP 
detachments),  a  slightly  different  automation  approach 
is  necessary.  This  MIS  has  been  termed  NALCOMIS  for 
Detachments  Subsystem  (NDS).  The  major  difference 
between  NALCOMIS/OMA  and  NDS  lies  in  the  direct 
communication  link  with  the  facility  which  processes 
data  (the  Data  Services  Facility)  for  the  AV-3M  system. 
NALCOMIS/OMA  will  have  that  capability  while  NDS  will 
not.  Maintenance  data  collection  and  processing 


24 


requirements  within  the  detachment,  however,  remain 
much  the  same  as  those  within  the  squadron. 

The  SNAP  I  contract  dictates  the  hardware  to  be 
used  for  NDS.  The  hardware  tentatively  selected  for 
NOS  Includes  [Kef.  9:p.  27]: 

1)  The  Central  Processing  Unit  [to  be]  a  Honeywell 
Personal  Computer  Advanced  Processor  with  4  MB  of 
memory  and  DPS  6/54  emulation  board. 

2)  Storage  media... one  80  MB  fixed  disk  drive. 

3)  The  output  devices. . .one  132  column  150  CPS  matrix 
printer  and  a  high  resolution  monochrome  monitor 
(color  monitor  with  RGB  may  be  used). 

4)  Input/Output  devices. . .one  1.2  MB  diskette  drive. 

Design  and  development  of  NALCOMIS/OMA  Is  ahead  of 

NDS.  Initial  design  for  NALCOMIS/OMA  had  been  com¬ 
pleted  and  development  had  begun  when  funding  became 
unavailable  In  July  1987.  Design  work  on  NDS,  however, 
was  Just  beginning. 

It  1 8  proposed  by  NAVMASSO  that  NDS  remain  as  much 
like  NALCOMIS/OMA  as  possible  since  there  are  many 
functional  similarities  between  the  two  systems  [Ref. 
10].  Nevertheless,  Improvements  In  design  from 
NALCOMIS/OMA,  such  as  screen  design,  are  to  be  Incorpo¬ 
rated  In  NDS  where  practical  [Ref.  11]. 

NDS  1 8  to  contain  only  those  essential  functions 
required  for  detachment  personnel  to  effectively  manage 
their  maintenance  business.  Ideally  It  might  be 


thought  of  as  a  subset  of  the  overall  NALCOMIS/OMA 
Incorporated  on  a  microcomputer. 


The  NDS  concept  Is  based  on  the  same  10  subsystems 
as  NALCOMIS/OMA,  with  only  streamlined  functions 
performed  by  each  subsystem.  Exactly  which  functions 
are  to  be  a  part  of  NDS  Is  yet  to  be  determined. 


C .  HARDWARE  COST 

Perhaps  the  most  Important  question  regarding  the 
future  of  automation  at  the  OMA  concerns  the  direction 
to  be  taken  when  funding  Is  once  again  available  for 
NALCOMIS/OMA.  The  cost  of  the  minicomputer  hardware 
specified  by  the  SNAP  contract  Is  estimated  at  $200,000 
per  squadron  [Kef.  12].  Coupled  with  the  fact  that 
there  are  approximately  400  0-level  squadron  mainte¬ 
nance  activities,  hardware  delivery  costs  alone 
approach  $80  million.  Due  to  these  and  other  expected 
long  term  maintenance  costs  [Ref.  13],  there  has  been 
discussion  at  the  Program  Manager  and  Central  Design 
Activity  levels  to  proceed  In  one  of  two  ways: 

1)  Have  sister  squadrons  share  hardware.  In  other 
words,  rather  than  placing  one  minicomputer  In  each 
parent  squadron,  each  minicomputer  should  be  shared 
by  two  (or  more)  squadrons,  or 

2)  Abandon  the  NALCOMIS/OMA  approach  and  replace  It 
with  NDS.  NDS  would.  In  effect,  become  Phase  III. 

Sharing  minicomputer  hardware  among  squadrons.  If 
such  an  option  were  to  prove  technically  feasible, 
would  certainly  cut  the  costs  of  hardware  considerably. 


L 


Of  primary  concern,  however.  Is  the  fact  that  when  a 
minicomputer  goes  down,  more  than  one  squadron  will 
have  to  shift  Into  a  contingency  mode  of  operations. 

No  one  Is  absolutely  sure  just  what  the  effects  of  a 
system  failure  will  be  on  a  squadron,  but  It  will 
present  an  undesirable  situation. 

D.  HARDWARE  AND  SOFTWARE  CONSTRAINTS 

In  attempting  to  discover  just  how  current 
NALCOMIS/OMA  plans  evolved,  the  author  was  concerned 
primarily  with  two  questions.  First  of  all,  why  Is 
NALCOMIS/OMA  being  developed  on  a  minicomputer? 
Secondly,  why  must  COBOL  be  used?  These  questions  were 
asked  In  order  to  gain  a  sense  of  understanding  for  how 
NALCOMIS/OMA  had  come  to  exist  as  It  currently  does. 

NALCOMIS/OMA,  In  Its  current  form,  did  not  emerge 
as  the  result  of  one  Individual’s  Ideas  about  Informa¬ 
tion  systems  design.  Rather,  It  Is  the  result  of  the 
thoughts  of  many  Individuals  and  groups  over  an 
extended  period  of  time.  It  also  appears  that  certain 
political,  as  well  as  design,  philosophies  have 
contributed  to  the  shaping  of  present  plans  for 
NALCOMIS/OMA. 

1 .  Standardization 

Most  simply  stated,  the  hardware  and  software 
constraints  placed  on  NALCOMIS/OMA  developers  are  the 
result  of  attempts  at  standardization.  The  SNAP 


contract,  tinder  which  NALCOMIS  falls,  "alms  to  stan¬ 
dardize  and  Integrate  the  Navy's  non-tactical  hardware 
and  software."  [Ref.  14 :p.  91] 
a.  Hardware 

Consider  the  minicomputer  environment  which 
is  planned  for  NALCOMIS/OMA.  That  particular  hardware 
was  selected  as  a  result  of  the  SNAP  contract  with 
Honeywell.  The  contract  is  a  binding  agreement  by 
which  those  Involved  in  the  design  and  development  of 
NALCOMIS/OMA  must  live.  Contrary  to  the  customary 
information  systems  design  and  development  process, 
however,  the  hardware  was  selected  before  the  require¬ 
ments  were  fully  known: 

During  a  system  design  project,  hardware  requirements 
are  typically  forecasted  only  after  the  functional 
design  of  the  system  has  been  completed.  During  the 
NALCOMIS  development,  a  preliminary  design  as  well  as 
a  fixed  hardware  environment  were  provided  as 
constraints  [Ref.  3:p.  25]. 

Although  there  are  definite  advantages  to 
standardization  In  a  general  sense,  determining  what 
sort  of  hardware  Is  to  be  used  before  requirements  for 
a  system  are  determined  places  many  constraints  on 
those  developing  the  system  and  usually  makes  those 
acting  as  Intermediaries  between  the  developer  and  user 
(e.g.,  NAVMASSO )  experience  many  frustrations  as  well. 
Those  frustrations  may  be  the  result  of  trying  to 
design  an  application  which  will  fit  the  hardware. 


As  currently  planned.  Implementing  NALCOMIS 
using  remote  work  station  terminals  means  that  automa¬ 
tion  will  be  limited  to  access  of  a  central  data  base. 
No  stand-alone  capabilities  will  exist  within  the  work 
center  Itself.  Placing  SNAP  I  hardware  at  the  squadron 
level  also  Imposes  certain  other  limitations: 

1)  The  number  of  possible  contingency  plans  which 
can  be  considered  is  reduced.  When  the  minicomputer 
is  down,  NALCOMIS  for  OMA  is  down. 

2)  Sharing  of  peripheral  devices  between  work 
stations  is  not  possible.  When  the  number  of 
peripheral  devices  (such  as  printers)  required  for 
one  OMA  is  multiplied  by  the  total  number  of  OMAs  to 
be  served  by  the  system,  this  limitation  can  greatly 
Increase  the  total  cost  of  hardware. 

Less  expensive  hardware  alternatives  could 
prove  equally  suitable.  For  Instance,  perhaps  some 
microcomputer  network  would  serve  the  same  (or  maybe 
greater)  purpose  than  a  more  costly  minicomputer. 

Strategic  planning  for  a  system  such  as 
NALCOMIS  isn’t  easy,  however.  Long  lead  times  are 
required  to  ensure  that  the  necessary  hardware  is 
available  when  needed.  Another  Important  factor  is  the 
long  lead  time  required  for  ship  alterations  [Ref.  15]. 
Hardware  cannot  merely  be  carried  on  board  ship  ready 
to  go.  The  ship  must  be  modified  (holes  cut  in 
bulkheads  where  necessary,  spaces  readied,  etc.)  in 
order  to  accommodate  the  hardware.  Not  only  does  this 
require  much  time  to  plan,  but  it  also  Incurs  major 


expenses . 


Therefore,  the  hardware  constraint  placed 
on  NALCOMIS  was  a  result  of  the  best  information 
available  at  the  time  such  decisions  were  made.  Since 
1982,  when  the  SNAP  contract  was  drawn  up,  technology 
has  changed  tremendously.  That  rapidly  changing 
technology  continues  today.  This  makes  strategic 
planning  for  MIS  extremely  difficult.  Since  we  can 
only  speculate  what  technology  will  exist  in  the 
future,  the  only  reasonable  course  of  action  in 
selecting  hardware  is  to  choose  the  best,  proven 
technology  in  existence  at  the  time  of  our  planning, 
b .  Software 

The  selection  of  COBOL  as  the  programming 

language  to  be  used  in  NALCOMIS/OMA  also  comes  from  a 

desire  to  achieve  standardization.  COBOL  has  become 

the  standard  throughout  much  of  the  business  world: 

The  widespread  acceptance  of  COBOL  stems  from  the 
ready  availability  of  COBOL-trained  programmers,  and 
the  considerable  body  of  existing  application 
programs  already  written  in  that  language ...  Organi¬ 
zations  using  COBOL  as  their  sole  language  are  not 
’locked*  into  a  particular  manufacturer’s  hardware, 
since  virtually  all  commercial  machines  have  avail¬ 
able  excellent  COBOL  compilers.  [Ref.  16:p.  348] 

When  considered  in  conjunction  with  the 
hardware  environment  selected,  COBOL  doesn’t  appear  to 
be  too  much  of  a  constraint.  Because  a  minicomputer 
and,  as  a  result,  NALCOMIS/OMA,  lends  itself  to  a  MIS 
which  performs  transaction  processing,  COBOL  is  perhap 
as  well  suited  as  any  other  language. 


If  NALCOMIS/OMA  were  being  developed  to 


allow  limited  or  extensive  stand-alone  computing 
capabilities,  then  we  might  become  concerned  about  the 
selection  of  COBOL.  Some  commercially  available 
applications  packages  might  provide  useful  capabilities 
to  maintenance  managers.  Lotus  123  and  other  software 
packages  are  already  being  used  to  produce  management 
reports  within  aviation  squadrons  (see  chapter  VII). 

Most  of  the  currently  available  packages 
are  not  written  in  COBOL,  however,  and  cannot  be  used 
in  NALCOMIS--because  COBOL  is  the  standard  [Ref.  15]. 
When  a  suitable  application  program,  but  one  written  in 
a  language  other  than  COBOL,  already  exists  commercial¬ 
ly,  it  is  not  even  considered  for  use  in  NALCOMIS.  One 
software  developer,  interviewed  for  this  thesis  (but 
wishing  to  remain  anonymous),  stated  that  he  would  not 
hesitate  using  a  commercially  available  software 
package  if  that  were  allowed.  By  finding  a  suitable 
package  already  in  existence  one  would  be  taking  full 
advantage  of  available  resources--and  saving  money  on 
unnecessary  development  costs. 

2 .  Control  Over  Squadron  Data 

One  further  point  concerning  the  minicomputer 
hardware  targeted  for  NALCOMIS/OMA  is  worth  considera¬ 
tion.  Selection  of  a  minicomputer  with  a  central  data 
base  allows  Aircraft  Controlling  Custodians  and  Type 


Commanders  greater  control  over  a  squadron's  data.' 

While  perhaps  not  apparent  at  first  glance,  this  is  a 
monumental  change  in  the  way  things  have  been  done  in 
the  past. 

Greater  control  over  a  squadron's  data  theo¬ 
retically  means  that  those  receiving  reports  can  be 
assured  that  the  organization  is  reporting  factual 
data.  In  effect,  a  squadron  loses  control  over  what  it 
reports.  For  example,  when  reporting  the  status  of 
aircraft  (i.e..  Mission  Capability),  the  squadron  pres¬ 
ently  prepares  the  reports  manually.  With  NALCOMIS, 
however,  squadron  managers  can  no  longer  manipulate  the 
data  to  be  reported. 

It  might  appear  initially  that  the  only 
motivation  a  squadron  has  for  manipulating  data  is  to 
improve  performance  statistics — making  the  squadron 
look  better  on  paper.  This,  however,  is  not  necessar¬ 
ily  the  case. 

The  purpose  of  a  status  report,  as  its  name 
implies,  is  to  provide  upper  management  with  a  summary 
of  a  squadron’s  status  (how  many  aircraft  are  avail¬ 
able,  how  many  are  flyable,  etc.).  The  usefulness  of 
such  a  report  to  upper  management  might  depend  somewhat 
on  the  report  being  reviewed  by  the  squadron  before  it 


is  sent  out. 


One  squadron  Maintenance/Material  Control 
Officer  (MMCO)  stated  that,  when  manually  reporting  the 
status  of  his  assigned  aircraft,  he  uses  his  judgement 
and  experience  to  determine  which  aircraft  are  up  and 
which  are  down.  If  he  has  the  resources  (e.g. ,  parts 
and  workers)  available  to  repair  an  aircraft  In  a  short 
period  of  time,  then  he  will  report  the  aircraft  up. 

Why  report  an  aircraft  down  if  It  will  be  repaired 
within  a  half-hour  or  so? 

If  data  is  reported  automatically  by 
NALCOMIS/OMA,  then  we  must  wonder  If  It  Is  painting  an 
accurate  picture  of  the  squadron's  readiness  posture. 
The  data  would  certainly  be  accurate  at  the  moment  that 
it  was  reported,  but  without  applying  Judgement  and 
expertise  of  the  squadron  manager,  It  might  become  very 
quickly  outdated. 

This  Issue,  while  political  in  nature,  must  be 
considered  In  order  to  fully  understand  Its  Implica¬ 
tions.  If  Aircraft  Controlling  Custodians  and  Type 
Commanders  want  a  more  accurate  picture  of  fleet 
performance,  then  will  this  gain  of  control  over 
squadron  data  provide  a  step  in  that  direction?  There 
are  several  other  things  to  keep  in  mind.  This  type  of 
automatic  reporting  system  could  result  in: 

1)  Performance  statistics  dropping  dramatically  and, 
as  a  result,  fleetwide  revision  of  performance  goals, 
and/or 


2)  Squadron  maintenance  managers  learning  how  to  work 
around  the  system  and  improve  their  performance 
statistics . 

While  It  Is  difficult  to  be  sure  what  the  full  effects 
of  higher  authority  gaining  greater  control  over 
squadron  data  will  be.  It  Is  possible  that  not  all  of 
the  effects  will  be  desirable. 

3 .  Project  Pressures 

While  plans  for  NALCOMIS/OMA  have  undergone 
much  reexamination  already,  some  of  those  plans  are 
still  under  scrutiny.  Changing  plans  costs  time  and 
money.  Therefore,  each  time  an  Issue  such  as  hardware 
selection  is  readdressed,  there  may  be  a  cost  involved. 
As  a  result,  there  Is  a  hesitancy  by  those  managing  the 
project  to  make  any  changes  in  plans. 

The  feeling  among  those  bearing  the  pressures 
of  managing  the  development  of  NALCOMIS/OMA  Is  that  the 

! 

project  must  be  continued  as  currently  planned.  A 
large  amount  of  money  has  already  been  spent  on  the 
!  current  plans  for  NALCOMIS/OMA  and  it  Is,  therefore, 

too  costly  to  make  any  major  changes  [Ref.  15] — an 

> 

understandable  feeling  given  such  a  burden  of  responsl- 

> 

|  blllty. 
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IV.  DEVELOPMENT  DECISIONS 


Tbe  purpose  of  this  chapter  is  to  point  out  some  of 
the  Issues  which  face  those  managing  the  development  of 
NALCOMIS/OMA.  Among  the  questions  which  they  must  face 
are : 

1)  How  can  NALCOMIS  provide  management  support  to 
squadron  maintenance  managers? 

2)  What  can  NALCOMIS  do  at  the  squadron  level  to 
Improve  mission  capability? 

3)  Should  NALCOMIS/OMA  be  further  developed  or  should 
NDS  be  expanded  to  meet  the  needs  of  the  OMA? 

The  first  two  questions  deal  with  the  objectives  of 
NALCOMIS — particularly,  providing  "modernized  manage¬ 
ment  support"  and  improving  "mission  capability."  [Ref. 
3 : pp.  3-4]  In  discussing  these  questions,  we  will 
attempt  to  identify  those  activities  in  the  OMA  which 
must  be  positively  affected  by  NALCOMIS/OMA  in  order  to 
benefit  from  computer  technology. 

Brookes  [Ref.  16 :p.  98]  points  out  that,  when 
defining  user  requirements,  it  is  "more  difficult  but 
more  potentially  rewarding  [to  identify]  the  opportuni¬ 
ties  for  a  new  system  to  make  a  major  Impact  on  a  key 
area  associated  with  the  success  of  the  business." 

Since  the  OMA  is  in  business  to  provide  mission  capable 
aircraft,  NALCOMIS/OMA  should  provide  its  greatest 
beneficial  Impact  in  that  area. 


The  third  question  deals  with  the  direction  which 
plans  for  NALCOMIS  Phase  III  will  be  taking  In  the  near 
future.  The  question  of  whether  or  not  NDS  should  be 
expanded  to  meet  the  needs  of  all  squadrons,  and  not 
Just  smaller  detachments,  will  be  presented  by  con¬ 
trasting  the  grand-design  and  plece-at-a-tlme  design 
approaches  [Ref.  17 :p.  26]. 

A.  NALCOMIS  AS  "MODERNIZED  MANAGEMENT  SUPPORT" 

This  section  will  attempt  to  provide  insight  lntc 
how  NALCOMIS  can  (and  should)  provide  support  to 
squadron  maintenance  managers.  The  value  of 
NALCOMIS/OMA  to  managers  will  be  discussed  by  distin¬ 
guishing  between  management  information  systems  (MIS) 
and  transaction  processing  systems.  Decision  making  In 
the  OMA  will  also  be  examined  In  order  to  determine 
those  key  areas  which  could  best  be  served  by 
NALCOMIS/OMA. 

1 .  MIS  versus  Transaction  Processing 

A  data  processing  system  processes  transactions 
and  produces  reports.  It  represents  the  automation 
of  fundamental,  routine  processing  to  support  opera¬ 
tions...  A  management  Information  system  Is  more 
comprehensive;  It  encompasses  processing  in  support 
of  a  wider  range  of  organizational  functions  and 
management  processes. . .Therefore,  the  significant 
Issue  1 8  the  extent  to  which  an  Information  system 
adopts  the  MIS  orientation  and  supports  the  manage¬ 
ment  functions  of  an  organization.  [Ref.  18:pp.  10- 
11] 

Is  NALCOMIS  for  OMA  as  currently  planned  a  true 
management  Information  system  or  Is  Its  purpose  solely 


that  of  transaction  processing?  It  might  be  quite 
useful  to  examine  this  issue  while  keeping  in  mind  what 
services  NALCOMIS  should  provide  to  the  OMA  in  the 
future . 

Once  again,  the  stated  objectives  of  NALCOMIS 
are  [Ref.  3:p.  3]: 

1)  Improved  Aircraft  Mission  Capability. 

2)  Improved  Aircraft  Maintenance  and  Supply  Support. 

3)  Improved  Reporting  to  Satisfy  Navy  and  Department 
of  Defense  Program  Requirements. 

4)  Modernized  Management  Support. 

In  understanding  how  to  plan  for  a  system  which 

will  adequately  meet  such  objectives,  it  is  necessary 

to  consider  how  the  organization  operates  Internally  in 

addition  to  how  it  Interacts  with  its  environment. 

King  [Ref.  19:p.  132]  states  that 

Both  Internal  and  external  constraints  must  be 
identified  if  MIS  Planning  is  to  be  effective.  These 
constraints  will  emanate  both  from  outside  and  within 
the  organization. 

The  most  obvious  forms  of  external  MIS  constraints 
are. . .reporting  requirements  and  the  need  for  the  MIS 
to  Interface  with  other  systems. 

Internal  constraints  emanate  from  the  nature  of  the 
organization,  its  personnel,  practices,  and  re¬ 
sources  . . . [many]  organizational  characteristics  serve 
to  limit  the  MIS *8  scope  and  nature.  For  Instance, 
the  degree  of  complexity  with  which  the  system  is 
Incorporated  may  be  constrained  because  of  the 
limited  sophistication  of  management,  the  lack  of 
experience  within  the  management  group  with  comput¬ 
ers,  or  demonstrated  distrust  of  sophisticated 
information  systems. 


The  external  constraints,  such  as  NAMP  report¬ 
ing  requirements  and  the  ability  to  interface  with 
Interim  and  future  systems  are  clearly  necessary  for 
NALCOMIS.  Objectives  2  and  3  above  address  these 
requirements  quite  adequately. 

If  there  exists  a  conflict  between  stated 
objectives,  however.  It  appears  to  lie  with  the  fourth 
objective  (discussion  of  the  first  objective  follows  In 
the  next  section).  Modernized  management  support  Is 
certainly  a  desirable  objective  of  any  MIS. 
NALCOMIS/OMA,  because  of  Its  use  of  on-line,  real-time 
computing,  might  surely  be  classified  as  modern.  The 
amount  of  management  support  that  It  will  provide, 
however,  remains  to  be  seen. 

"The  on-line,  real-time  nature  of  the  system 
will  provide  the  needed  response  time  to  support  dally 
activities  and  provide  timely  Information  to  local 
managers."  [Ref.  3:p.  4]  While  this  statement  Is 
somewhat  general.  It  Is  Important  to  realize  that 
NALCOMIS  Is  attempting  to  provide  management  support 
through  on-line,  real-time  features. 1 

To  a  great  extent  NALCOMIS  automates  existing 
procedures.  To  change  the  maintenance  data  collection 

^Some  of  the  reactions  that  maintenance  managers 
have  had  with  these  features  will  be  discussed  In 
Chapter  V.  For  now  we  will  limit  our  discussion  to  the 
activities  performed  by  the  maintenance  manager  and  the 
Information  he  uses  In  performing  them. 


and  reporting  procedures  that  have  evolved  over  time 
would  be  an  enoraous  disruption  of  the  maintenance 
effort  at  all  levels.  Therefore.  It  Is  reasonable  to 
expect  that  NALCOMIS  will.  In  many  ways,  resemble  the 
existing  (NAMP)  manual  system.  This  does,  however, 
then  cause  one  to  wonder  how  much  better  off  management 
decisions  will  be  because  of  the  new  system. 

Dickson  [Ref.  20 :p.  82]  says  that 

When  a  system  provides  Information  to  be  used  In  the 
managerial  decision  process,  then  It  Is  a  true 
Information  system. . .A  true  Information  system  Is  not 
aimed  at  the  processing  of  data  as  Is  a  clerical 
system.  Thus,  payroll  systems,  accounts  payable  and 
receivable  systems,  and  even  many  Inventory  systems, 
although  computerized,  are  not  Information  systems. 
Furthermore,  an  Information  system  contains  Informa¬ 
tion.  not  data;  the  content  of  the  system  output  Is 
not  a  vast  sea  of  numbers,  but  conveys  a  message  to 
the  decision  maker. 

While  an  endless  number  of  equally  sufficient 
definitions  may  be  applied  to  management  Information 
systems  and  transaction  processing  systems,  one  could 
say  that  NALCOMIS/OMA  fits  the  definitions  of  both. 
There  may  be  no  clear  distinction  In  the  case  of 
NALCOMIS/OMA.  But  what  could  be  argued  Is  to  what 
extent  will  NALCOMIS/OMA  provide  management  support? 

2.  Decision  Making  In  the  Squadron 

Different  levels  of  the  hierarchy  Involved  In 
aviation  maintenance  require  different  Information. 

The  Aircraft  Controlling  Custodian  and  Type  Commander 
usually  require  reports  which  contain  very  aggregate 


and  summarized  data  (refined  and  summarized  so  that  the 
data  becomes  meaningful  information).  The  Commanding 
Officer  of  the  squadron,  while  still  Interested  In 
reviewing  those  same  reports,  will  often  require  that 
somewhat  more  detailed  Information  be  supplied  to  him. 
The  Maintenance/Mater lal  Control  Officer,  Maintenance 
Chief  Petty  Officer,  and  work  center  supervisors,  on 
the  other  hand,  sort  through  much  data  in  order  to 
obtain  the  Information  required  to  make  their  deci¬ 
sions. 

Generally  speaking,  the  further  down  the  chain 
of  command  one  moves,  the  more  detailed  the  data 
becomes.  This  generality  occurs  due  to  the  nature  of 
decisions  which  must  be  made  at  each  level  In  the  chain 
of  command.  Data  becomes  Information  when,  somehow.  It 
Is  manipulated  so  that  It  becomes  meaningful  [kef. 

18:p.  9] .  This  Information,  then.  Is  used  for  making 
decisions.  It  follows  that,  since  different  types  of 
decisions  must  be  made  at  different  levels  In  the 
hierarchy,  different  Information  Is  required  throughout 
the  chain  of  command. 

a.  Types  of  Decisions 

Lucas  [Ref.  21 :p.  29]  Identifies  three 
types  of  decisions  which  are  made  in  organizations: 
strategic,  managerial  control,  and  operational  control. 
By  examining  each  of  these  categories  briefly,  we  will 


be  better  able  to  understand  hov  NALCOMIS  can  help 

improve  decision  making  at  the  squadron  level. 

The  first  area  is  strategic  planning  in  which  the 
decision  maker  develops  objectives  and  allocates 
resources  to  obtain  these  objectives.  Decisions  in 
this  category  are  characterized  by  long  time  periods 
and  usually  Involve  a  substantial  Investment  and 
effort . 

Decisions  that  are  classified  as  managerial  control 
in  nature  deal  with  the  use  of  resources  in  the 
organization  and  often  Involve  personnel  or  financial 
problems.  For  example,  an  accountant  may  try  to 
determine  the  reason  for  a  difference  between  actual 
and  budgeted  costa. 

Operational  control  decisions  deal  with  the  day-to- 
day  problems  that  affect  the  operation  of  the  firm. 
What  should  be  produced  today  in  the  factory?  What 
items  should  be  ordered  for  Inventory? 

Lucas  further  describes  the  characteristics 
of  the  information  that  is  associated  with  the  three 
types  of  decisions  mentioned  (see  Table  1)  [Ref.  21 :p. 
29].  Information  which  is  used  in  making  strategic 
decisions,  for  example,  is  typically  "predictive  and 
long  range  in  nature."  Data  which  comes  from  sources 
external  to  the  organization  is  often  used.  Also, 
"summary  information  on  a  periodic  basis  [may  be] 
adequate . " 

Historical  information,  most  often  gathered 
from  within  the  organization,  is  used  in  making 
operational  control  decisions.  Lucas  also  points  out 
that  "the  data. . .must  be  detailed.  Because  we  are 
working  with  the  day-to-day  operations  of  the  firm. 


operational  control  Information  Is  often  required  In 
close  to  real  time." 


TABLE  1 

INFORMATION  CHARACTERISTICS  VERSUS  DECISION  TYPES 


Oecislen  type 

Characteristics 

Operational  control 

Managerial  control 

Strategic  planning 

Tims  frame 
Expectation 
Source 

Scope 

Frequency 

Organisation 

Accuracy 

Historical 

Anticipated 

Largely  internal 
Detailed 

Real  lime 

Highly  structured 
Highly  accurate 

- p 

— - > 

— - -  » 

> 

- ► 

- p 

Predictive 

Surprise 

Largely  external 
Summary 

Periodic 

Loosely  structured 
Not  overly  accurate 

As  shown  In  Table  1  [Ref.  21 :p.  29],  the 
Information  required  In  making  managerial  control 
decisions  takes  on  characteristics  somewhere  between 
those  of  strategic  planning  and  operational  control. 
Some  managerial  control  decisions  might  call  for 
detailed  Information  while  others  may  only  require 
summarized  Information. 

b.  Classifying  Maintenance  Decisions 

i 

It  might  be  difficult  to  classify  each 
decision  made  within  the  OMA  as  one  of  the  three  type 
mentioned  above.  There  Is  not  always  a  fine  line 

i 

between  an  operational  control  decision  and  a  manage¬ 
rial  control  decision.  Some  generalization,  however, 

might  be  possible. 

i 


Strategic  planning  decisions,  for  the  most 
part,  take  place  outside  the  squadron.  Certainly,  most 
strategic  decision  making  takes  place  outside  the 
maintenance  department.  Operational  and  managerial 
control  decisions,  on  the  other  hand,  take  up  a  great 
deal  of  maintenance  managers’  time.  Since  we  are 
trying  to  determine  how  maintenance  managers  can  best 
be  provided  with  management  support,  our  discussion 
will  focus  on  operational  and  managerial  control 
decisions . 

Managerial  control  decisions  can  be  thought 
of  as  taking  place  within  the  OMA  primarily  between  the 
Department  Head  (Maintenance  Officer)  and  the  Division 
Officer  levels .  The  Material  Control  Officer,  for 
example,  might  be  concerned  that  the  squadron’s 
operational  cost  per  flight  hour  for  the  current 
quarter  Is  well  above  that  of  the  previous  quarter.  He 
may  examine  numerous  factors  In  trying  to  determine  a 
cause  for  the  Increase:  the  type  of  missions  flown  this 
quarter:  the  price  of  aviation  fuel;  unusual  mainte¬ 
nance  tasks,  etc.  Once  he  Is  satisfied  that  he  knows 
what  caused  the  Increase,  he  can  then  make  a  decision 
as  to  what  action  should  be  taken  (or,  to  take  no 
action ) . 

Somewhere  below  the  division  officers  in 
the  squadron’s  chain  of  command,  operational  control 


decisions  are  made — those  decisions  dealing  with  the 
"day-to-day  problems"  which  exist  in  the  squadron.  The 
Maintenance  CPO,  for  instance,  is  constantly  analyzing 
and  prioritizing  discrepancies  (needed  repairs  or  other 
maintenance  actions).  He  decides  which  work  center 
should  receive  each  discrepancy,  which  aircraft  should 
be  repaired  next,  when  scheduled  maintenance  can  be 
performed--decisions  which  require  constant  awareness 
of  the  overall  maintenance  situation. 

Work  center  supervisors,  likewise,  must  be 
aware  of  the  situation  within  their  own  work  centers. 
They  must  know  who  is  qualified  (and  available)  to  work 
on  a  particular  discrepancy,  what  priorities  exist 
within  the  work  center — how  to  best  employ  their 


resources . 


The  management  decisions  which  take  place 


within  the  Maintenance  Department,  then,  are  primarily 
of  the  operational  and  managerial  control  types.  It 
would,  therefore,  seem  most  beneficial  to  place  the 
appropriate  amount  of  development  emphasis  on  ensuring 
that  NALCOMIS  supports  those  decision  making  functions. 

3.  Supporting  Management  with  NALCOMIS 


As  we  move  down  the  management  chain  of  command 
from  the  Maintenance  Officer  to  the  maintenance  CPO  and 
work  center  supervisor,  the  need  for  information 
generally  changes  to  that  which  is  more  detailed  and 


real-time  in  nature  than  that  which  is  reported  outside 
the  command.  It  might  prove  helpful,  therefore,  to 
examine  current  plans  for  NALCOMIS/OMA  and  try  to 
determine  whether  or  not  those  plans  are  likely  to 
provide  managers  with  the  type  of  information  necessary 
to  improve  their  decision  making. 

a.  Managerial  Control  Decisions 

As  stated  earlier,  it  is  difficult  to  make 
generalizations  concerning  the  information  required  to 
make  managerial  control  decisions.  Sometimes  the 
information  is  required  to.be  real  time  and  detailed, 
while  other  times  summary  information  is  sufficient. 

NALCOMIS/OMA,  as  currently  proposed,  will 
certainly  offer  at  least  some  benefits  to  those  making 
managerial  control  decisions.  Pre-defined  reports 
should  be  received  with  little  manual  effort  and 
hopefully  with  some  greater  speed  and  accuracy.  Notice 
that  greater  accuracy  implies  "less  chance  for  con¬ 
flicting  data"  and  not  necessarily  "more  correctness." 
As  long  as  there  are  human  sources  of  data  involved, 
there  is  chance  for  incorrect  data. 

One  report  currently  available  to  manage¬ 
ment  is  the  Not  Mission  Capable  Supply/Partial  Mission 
Capable  Supply  (NMCS/PMCS)  Report  which  gives  a  daily 
listing  of  aircraft  which  are  awaiting  parts  from  the 
supply  system,  the  supply  documents  which  requested  the 
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parts,  and  the  status  of  those  documents.  This  report 
is  usually  published  so  that  it  is  available  at  the 
beginning  of  each  morning  work  shift,  and  it  gives 
maintenance  managers  an  overall  view  of  how  the  supply 
situation  will  affect  their  maintenance  plans  for  the 
day. 

One  of  the  greatest  benefits  of  NALCOMIS  at 
the  squadron  level  will  be  the  interface  it  will 
provide  between  the  Supply  Support  Center  (SSC)  and  the 
OMA.  Maintenance  Chiefs  constantly  require  information 
on  the  status  of  parts  and  components  which  are  on 
order  from  the  supply  support  center.  By  knowing  when 
these  parts  will  be  delivered  to  the  squadron,  the 
maintenance  CPO  (and  other  managers)  will  be  able  to 
make  decisions  concerning  cannibalization  actions  and 
schedule  commitments.  An  on-line  interface  with  Supply 
should  give  more  timely  forecasts  of  delivery  times  and 
dates.  Such  an  interface,  in  addition  to  allowing  the 
tracking  of  supply  documents,  will  also  speed  up  the 
process  of  ordering  itself. 

NALCOMIS  must  provide  reports  to  the 
decision  makers  which  contain  the  right  information 
(and  in  the  right  format),  and  its  on-line  features 
must  be  fast  and  easy  to  use.  In  other  words, 
NALCOMIS/OMA  must  provide  squadron  managers,  from  the 
Maintenance  Officer  to  the  division  officers,  with 


better  support  than  they  are  receiving  with  the  current 
manual  system. 

b.  Operational  Control  Decisions 

As  we  move  further  down  the  squadron’s 
chain  of  command--to  the  maintenance  CPO  and  work 
center  supervisors--the  decisions  which  are  made 
require  even  more  detailed,  real-time  data.  These 
decisions,  once  again,  are  operational  control  deci¬ 
sions  . 

Those  making  the  day-to-day  decisions  will 
also  have  two  basic  ways  of  obtaining  information  from 
NALCOMIS:  by  report  (or  notice)  and  on-line.  But  as 
more  and  more  detail  is  required  by  these  managers,  it 
will  become  more  likely  that  pre-defined  reports  will 
not  satisfy  their  information  needs. 

Very  often,  data  reported  up  the  chain  of 
command  is  of  little  benefit  (in  its  reported  form)  to 
those  making  operational  control  decisions  within  the 
squadron.  All  too  frequently,  the  less  experienced 
local  manager  is  even  unaware  of  the  purpose  that  such 
data  will  serve.  Some  reports  are  viewed  more  as 
unnecessary  paperwork  than  useful  reports. 

Since  the  reports  generated  by  NALCOMIS/OMA 
will  be  pre-defined,  their  value  to  lower  level 
management  might  be  questioned.  As  Beishon  [Ref  22:p. 
311]  states: 


In  a  situation  where  our  understanding  of  how  a  man 
does  his  Job  is  very  limited,  it  is  surely  rather 
dangerous  to  make  a  priori  judgements  about  the 
information  he  is  going  to  need.  Perhaps  more 
Important  still,  there  is  a  more  serious  danger 
in  deciding  arbitrarily  about  the  information  we 
think  he  will  not  need  and  which,  in  consequence,  we 
keep  from  him.  Management  is  still  rightly  regarded 
as  a  peculiarly  human  skill  precisely  because, 
although  we  can  aid  the  manager,  we  cannot  replace 
him  by  explicit  sets  of  rules  for  action,  or  even  by 
mathematical  equations.  Since  we,  and  to  a  large 
extent  managers  themselves,  do  not  consciously  know 
how  they  reach  their  decisions  or  why  they  make  a 
good  rather  than  a  bad  one,  we  must  be  especially 
careful  in  limiting  or  formalising  their  information 
sources.  In  the  absence  of  specific  research 
findings  in  the  area  it  would,  on  the  face  of  it, 
seem  more  sensible  to  allow  the  manager  more  freedom 
to  build  up  his  own  information  system  on  a  trial  and 
error  basis  and  to  study  these  systems  in  the  light 
of  their  effectiveness. 

It  is  reasonable  to  expect  that  maintenance 
managers  will  want  (and,  in  many  ways,  need)  the 
ability  to  examine  and  manipulate  some  data  in  a  manner 
that  will  accommodate  the  ways  in  which  they  make 
— individual,  decisions.  (See  chapter  VIII  for  further 
discussion  on  manipulation  of  data. ) 

Since  NALCOMIS  does  not  allow  managers  to 
freely  create  and  format  their  own  reports  [Ref.  10], 
some  other  way  of  satisfying  their  information  require¬ 
ments  must  be  made  available.  In  the  absence  of  the 
capability  of  creating  customized  reports,  the  on-line 
capabilities  of  NALC0MIS/0MA  must  provide  quick  and 
easy  access  to  the  information  needed  to  make  deci¬ 


sions  . 


B.  NALCOMIS  AND  "MISSION  CAPABILITY" 

NALCOMIS/OMA  will  attempt  to  Improve  mission 
capability  in  a  couple  of  ways  [Ref.  3:p.  3].  First, 
through  "more  accurate  and  timely  processing  of  data, 
the  organizational  levels  will  be  able  to  better  manage 
and  take  action  on  the  information  provided  by  the 
system  [NALCOMIS]."  Secondly,  by  reducing  "delays  due 
to  awaiting  maintenance  (AWM)  and  awaiting  parts 
( AWP ) , "  a  greater  aircraft  availability  (and,  thus, 
mission  capability)  can  be  achieved. 

Improving  decision  making  and  reducing  delays  due 
to  AWM  and  AWP,  while  critical  to  increasing  mission 
capability  rates,  are  not  the  only  things  that  informa¬ 
tion  technology  can  do  to  improve  mission  capability  at 
the  OMA.  It  is  possible  that  automation  could  also 
Improve  productivity  at  lower  levels — particularly  at 
the  work  center  level. 

It  is  the  purpose  of  this  section  to  show  that 
mission  capability  depends  on  worker  productivity  as 
well  as  good  decision  making.  After  discussing 
maintenance  and  operational  commitments  which  exist  at 
the  squadron,  we  will  suggest  what  NALCOMIS/OMA  must  do 
in  order  to  Improve  worker  productivity  and,  as  a 
result.  Improve  mission  capability  rates. 


1 .  Maintenance  and  Operational  Commitments 

There  Is  a  distinct  relationship  between 
maintenance  tasks  and  operational  commitments  In  the 
OMA.  While  operational  commitments  are  usually  known 
well  In  advance,  maintenance  on  naval  aircraft  most 
often  takes  place  as  a  result  of  the  unexpected  failure 
of  some  component  or  subsystem  In  the  aircraft.  Such 
failures  make  the  management  of  naval  aircraft  mainte¬ 
nance  difficult  and  filled  with  uncertainty. 

Maintenance  tasks  can  be  classified  as  belong¬ 
ing  to  one  of  two  categories:  "scheduled"  or  "unsched¬ 
uled"  maintenance.  Scheduled  maintenance  Is  defined  as 
"periodic  prescribed  Inspection  [or]  servicing  of 
equipment,  done  on  a  calendar,  mileage,  or  hours  of 
operation  basis."  [Ref.  7:p.  C-38]  "Maintenance,  other 
than  the  fix  phase  of  scheduled  maintenance,  occurring 
during  the  Interval  between  scheduled  downtime  mainte¬ 
nance  periods,"  Is  unscheduled  maintenance  [Ref.  7:p. 
C-44 ] . 

Similarly,  for  purposes  of  this  thesis,  we 
might  classify  operational  commitments  as  either 
planned  or  unplanned.  Planned  commitments  are  those 
commitments  which  are  known  well  In  advance,  e.g., 
those  which  can  be  worked  Into  a  monthly  operational 
plan.  Unplanned  commitments  are  those  which  are 
scheduled  on  lesser  notice.  For  example,  a  squadron 


might  he  called  upon  to  provide  tanker  support  when 
another  previously  committed  squadron  Is  unable  to 
provide  a  tanker  for  the  mission. 

It  Is  useful  to  think  in  terms  of  a  simple  two- 
by-two  matrix  while  considering  the  effects  of  the 
possible  combinations  of  occurrences  on  the  organiza¬ 
tion  and  Its  personnel.  There  are  four  possible 
combinations  (see  Table  2):  planned-scheduled , 
unplanned-scheduled ,  planned-unscheduled,  and 
unplanned-unscheduled . 

TABLE  2 

OPERATIONAL  MAINTENANCE 

COMMITMENTS  TASKS 

1)  planned  scheduled 

2)  unplanned  scheduled 

3)  planned  unscheduled 

4)  unplanned  unscheduled 

In  a  planned-scheduled  situation,  both  Opera¬ 
tions  and  Maintenance  are  operating  tinder  the  greatest 
degree  of  certainty.  Coordination  between  the  two 
departments  is  high,  and  as  a  result,  missions  are 
completed  and  there  are  minimal  pressures  on  the 
organization  and  Its  Individuals.  Unfortunately,  this 
situation  occurs  too  Infrequently. 

The  unplanned-scheduled  scenario  presents  less 
certainty,  but  the  situation  Is  still  quite  manageable. 
Through  minimal  coordination.  Operations  simply  asks 
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Maintenance  whether  or  not  It  can  handle  the  extra 
coultaent,  and  a  yes/no  decision  Is  made.  While  a 


Commanding  Officer  would  prefer  to  provide  air  support 
any  time  he  Is  called  upon  to  do  so,  his  decision  Is 
based  on  how  many  aircraft  are  available. 

The  planned-unscheduled  combination  occurs  most 
frequently.  (The  Maintenance  Master  CPO  In  the 
squadron  visited  during  research  for  this  thesis 
estimated  that  this  situation  occurs  approximately  85* 
of  the  time. )  Operational  commitments  are  known  well 
In  advance  but  aircraft  systems  fall  according  to 
Murphy's  Law.  This  situation  Is  marked  by  schedule 
pressures  and  flight  cancellations,  both  brought  on  by 
the  uncertainty  generated  by  aircraft  going  down. 
Pressure  Is  on  not  only  Operations  to  prioritize  and 
rewrite  Its  flight  schedule,  but  on  maintenance  _  _ 
managers  and  work  center  personnel  to  fix  the  aircraft 
as  well. 

The  last  case,  unplanned-unscheduled,  while 
occurring  less  frequently  them  the  previous  case,  again 
puts  pressure  on  both  departments.  The  maximum  degree 
of  uncertainty  involved  makes  it  difficult  for  the 
Operations  Officer  to  decide  whether  or  not  he  can 
accept  an  added  commitment.  He  does  not  want  to  turn 
down  a  commitment  that  he  can  possibly  meet,  and  yet, 
at  the  same  time,  he  does  not  want  to  commit  to  a 
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mission  and  then  be  faced  with  the  embarrassment  of 
explaining  why  he  missed  It  after  all. 

Vhlle  these  mixes  of  operational  and  mainte¬ 
nance  situations  occur  In  various  combinations  at  any 
one  time.  It  Is  Interesting  to  note  that  the  most 
frequent  occurrence,  planned-unscheduled,  also  places 
pressure  on  the  organization  and  Its  Individuals. 
Decreased  mission  completion  rates  and  mission  capabll 
lty  are  the  results. 

2 .  Beneflttlng  From  Automation 

How,  then,  should  NALCOMIS/OMA,  serve  to 
Improve  upon  the  mission  capability  of  the  squadron? 
Although  It  cannot  directly  reduce  the  frequency  with 
which  aircraft  systems  break  down.  It  could  contribute 
to  Improved  management  decisions  and  free  workers  and 
work  center  supervisors  from  some  of  their  administra¬ 
tive  workload.  Besides  the  Importance  of  making  fast, 
correct  decisions  about  aircraft  maintenance  (by 
managers  at  every  level),  the  other  critical  factor 
which  la  necessary  to  Improve  mission  capability  is 
worker  productivity. 

a.  Better  Decision  Making 

Providing  useful  and  timely  Information  to 
maintenance  managers  is  one  of  the  ways  In  which 
NALCOMIS  will  contribute  to  Improved  mission  capablll- 


ty.  When  managers  have  the  right  Information  at  the 
right  time,  they  can  make  better  decisions. 

As  mentioned  previously,  NALCOMIS  must 
provide  maintenance  managers  vlth  Information  pertinent 
to  the  decision  at  hand  vhen  it  Is  needed.  If  this 
Information  Is  provided,  then  NALCOMIS  has  done  all 
that  It  can  be  expected  to  do  to  help  In  the  decision 
making  process.  Whether  or  not  the  correct  decision  is 
made  will  depend  upon  the  decision  maker  himself. 

At  the  work  center  level,  the  work  center 
supervisor  also  makes  decisions  vhlch  affect  mission 
capability.  He  must  decide  vhlch  personnel  should  be 
assigned  to  certain  Jobs,  vhlch  discrepancies  need  to 
be  repaired  next,  etc.  He  must  be  provided  vlth  (or 
seek)  the  pertinent  Information  to  make  those  deci¬ 
sions. 

b.  Productivity 

Worker  productivity  also  Influences  mission 
capability  rates.  Productivity  does  not  depend  upon 
Information  as  much  as  decision  making  does,  though. 

The  primary  factor  In  determining  productivity  is 
simply  hov  much  constructive  time  vorkers  spend 
repairing  aircraft  discrepancies.  Aircraft  cannot  be 
repaired  by  proper  management  alone.  Manpover  is 
required. 
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Productivity  does  depend  somewhat  on 
information,  however.  For  Instance,  time  Is  not  spent 
very  productively.  If,  In  trying  to  fix  a  discrepancy, 
a  worker  replaces  a  component  that  was  not  faulty  in 
the  first  place.  Possessing  the  wrong  Information  or 
Interpreting  Information  Incorrectly  can  lead  to 
decreased  productivity.  Productivity,  nevertheless, 
depends  mostly  on  workers  spending  as  much  of  their 
time  as  possible  directly  on  aircraft  repairs. 

What  sort  of  activities  take  workers  away 
from  direct  maintenance?  While  this  question  was  not 
addressed  In  great  detail  during  the  research  trip  to 
the  OMA,  these  activities  should  be  Identified  to 
determine  what,  if  any,  help  NALCOMIS/OMA  can  provide 
In  reducing  time  spent  on  these  activities. 

One  quite  obvious  group  of  activities  was 
noticed  during  the  visit  to  the  OMA,  however.  These 
activities,  which  can  be  termed  administrative  tasks, 
consist,  to  a  large  extent,  of  collecting,  documenting, 
and  verifying  data. 

The  VIDS/MAF,  as  will  be  seen  In  chapter 
VI,  Is  one  of  the  current  means  of  collecting  data. 

Data  Is  entered  on  the  form  and  checked  for  accuracy 
and  validity  by  numerous  Individuals  throughout  the 
maintenance  department — for  each  single  discrepancy 
which  Is  discovered.  At  the  work  center  level,  any 
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aaount  of  time  which  can  be  saved  In  collecting, 
entering,  and  verifying  data  on  the  VIDS/MAF  can  be 
spent  In  the  actual  repair  of  aircraft.  This  could 
aaount  to  quite  a  significant  aaount  of  tlae  when  the 
large  nuaber  of  VIDS/MAFs  handled  by  the  squadron  Is 
considered . 

What  NALCOMIS  aust  do  for  the  worker,  then. 
Is  provide  fast  and  easy  access  to  the  systea,  fast  and 
accurate  data  entry,  and  check  the  worker's  entries  for 
validity.  If  NALCOMIS  does  not  provide  these  services 
In  a  way  which  Is  better  than  the  current  annual 
systea,  then  It  Is  questionable  whether  NALCOMIS  can 
significantly  laprove  mission  capability. 

C.  NALCOMIS/OMA  OR  EXPANDED  NDS? 

The  Navy  Manageaent  Systeas  Support  Office  and  the 
NALCOMIS  prograa  nan age r  (PMA-270)  have  expressed 
uncertainty  as  to  the  future  of  Phase  III  development 
[Ref.  10].  Due  to  the  long-term  costs  Involved  In 
developing  and  maintaining  NALCOMIS/OMA  as  currently 
planned,  the  following  question  has  been  posed:  Should 
NALCOMIS/OMA ,  as  currently  defined,  be  further  devel¬ 
oped  and  tested,  or  should  the  NALCOMIS  for  Detachments 
Subsystea  (NDS)  become  a  basic  building  block  and 
expanded  as  necessary  to  meet  the  requirements  of 
larger  maintenance  activities  [Ref.  13]? 


In  this  section,  the  question  of  whether  or  not  NDS 
should  be  expanded  to  meet  the  needs  of  all  squadrons. 


and  not  just  smaller  detachments,  will  be  examined  by 
contrasting  the  grand-design  and  plece-at-a-tlme  design 
approaches  [Sef.  17 :p.  26].  Also,  some  of  the  criteria 
for  determining  an  effective  baseline  system  are 
presented. 

1.  Complexity  of  NALCOMIS/OMA 

During  several  visits  to  a  typical  O-level 
maintenance  activity,  maintenance  managers  were  asked, 
"Have  you  heard  of  NALCOMIS?"  The  reply  most  often 
heard  was,  "Yes,  I’ve  heard  about  It  for  years  but  I’ve 
never  seen  anything  on  It."  While  this  response  Is 
understandable,  the  feelings  of  maintenance  managers 
toward  NALCOMIS  were  usually  one  of  several  commonly 
held  views: 

1)  Either  they  held  no  strong  opinion  of  the  system, 

2)  They  felt  that  the  system  Is  so  complex  that  they 
may  never  see  It  completed,  or 

3)  They  expect  to  see  NALCOMIS  at  the  squadron  level, 
but  perceive  the  delay  as  being  Indicative  of  some 
dreadfully  complicated  system  that  will  Just  have  to 
be  dealt  with  someday. 

Almost  without  exception,  however,  each  Individual 
agreed  that  a  better  way  of  collecting  and  handling 
maintenance  data  Is  needed.  Many  also  felt  that  a 
computer  system  Is  the  logical  choice  to  handle  the 


complex  administrative  tasks  required  of  today’s  Naval 
Aviation  squadrons. 

The  OMA  is  unique  in  that  it  is,  in  many  ways , 
a  self-contained  unit  which  carries  out  not  only 
maintenance  activities,  but  operational  and  administra¬ 
tive  activities  as  well.  While  it  is  dependent  upon 
other  organizations  for  support  and  policy  guidance  in 
each  of  these  areas,  it  is  nonetheless  unique. 

What  this  unique  structure  means  is  that  a 
fully  Integrated  MIS  for  the  OMA  has  the  possibility  of 
being  extremely  complex.  Besides  needing  information 
processing  and  management  capabilities  for  each  of  the 
individual  activities  mentioned  above,  all  three 
activities  must  be  capable  of  interacting  with  one 
another  to  some  extent  if  the  OMA  is  to  possess  a  full 
MIS  capability. 

Even  an  information  system  which  were  to  be 
limited  to  only  the  Maintenance  Department  v-mld  be 
very  complex  by  nature.  Just  as  Interdepartmental 
exchanges  of  information  take  place  among  the  Mainte¬ 
nance,  Administrative,  and  Operations  departments, 
lntradepartmental  exchanges  take  place  within  the 
Maintenance  Department  Itself.  This  potential  complex¬ 
ity  becomes  Important  in  deciding  just  how  much 
information  system  should  be  heaped  upon  the  OMA 
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Grand-Design  versus  Plece-At-A-Tlme 


There  are  several  reasons  why  a  complex  MIS 


such  as  NALCOMIS/OMA  (as  currently  planned)  might  not 


be  successfully  Implemented  within  the  OMA  all  at  once 


Besides  the  users'  resistance  to  change,  several  other 


factors  make  initial  delivery  of  a  basic,  no-frills 


system  an  attractive  alternative. 


1)  A  complete  MIS  takes  longer  to  develop  than  a 
system  with  less  capability.  The  longer  development 
time  of  a  more  complex  MIS  could  mean  delays  in 
delivery  of  some  smaller  baseline  system  to  fleet 
users . 


2)  Delivering  NALCOMIS/OMA  all  at  once  would  mean 
that  less  feedback  on  the  system's  performance  could 
be  Incorporated  into  the  initial  version.  While 
prototyping  would  have  taken  place,  it  would  be 
desirable  to  receive  feedback  on  a  baseline  NALCOMIS 
while  other  subsystems  were  being  developed  and 
phased  into  the  OMAs. 


3)  Problems  would  be  more  easily  corrected  in  a  less 
complex  system.  It  would  be  most  desirable  to  have 
any  problems  in  the  ini tlaT- NALCOMIS/ OMA  resolved 
before  a  fully  Integrated  MIS  were  Installed. 


Robert  Head  [Ref.  23 :p.  95]  states  in  "The 


Elusive  MIS"  that 


Most  practitioners  agree  that  a  system  of  major 
scope,  especially  one  that  cuts  across  organizational 
lines  and  Involves  numerous  organizational  compo¬ 
nents,  should  be  Implemented  gradually.  Rather  than 
work  toward  a  day  several  years  in  the  future  when  an 
entire  grandiose  scheme  goes  "on  stream,"  it  is 
better  to  Implement  the  system  in  chunks  or  pieces. 


Booth  terms  these  two  approaches  "the  grand- 


design  approach"  and  "the  piece-at-a-time  approach" 


[Ref.  17:p.  26]: 
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The  grand-design  approach. .. can  ensure  that  all 
functions  and  all  parts  of  the  system  fit  together 
well.  In  addition,  in-depth  analysis  of  the  entire 
system  prior  to  implementation  ought  to  minimize  the 
possibility  of  surprises — discovering  new  require¬ 
ments  after  implementation  has  begun,  or  even  after 
it  is  complete. 

The  piece-at-a-time  approach. .. is  often. . .appreciated 
by  system  users.  System  users  and  their  management 
generally  like  this  approach  because  they  receive 
some  payback  in  system  benefits  relatively  quickly. 
They  are  also  less  likely  to  face  traumatic  changes 
as  each  piece  of  the  total  system  is  implemented.  If 
changes  in  operational  methods  and/or  the  structure 
of  the  organization  are  required,  it  may  be  possible 
to  make  these  modifications  gradually. 

Booth  also  states  that  "the  piece-at-a-time 
approach  is  particularly  advantageous — and  the  grand- 
design  approach  especially  risky "  when  trying  to 
Implement  poorly  understood  functions,  such  as  those 
performed  by  managers.  He  concludes  that  "the  proba¬ 
bility  of  creating  a  truly  successful  system  may  be 
hJ gher— wl-th.  th  1  a  method,  [ the  piece-at-a-time  approach] 
than  with  the  grand-design  approach." 

3 .  Determining  a  Baseline 

Ideally  one  would  hope  that  NALCOMIS./OMA  could 
be  delivered  to  the  user  at  the  same  rate  at  which  it 


was  gaining  his  acceptance.  Although  it  would  be 
virtually  impossible  to  precisely  determine  this  rate, 
it  would  be  desirable,  particularly  in  a  large  and/or 
complex  system,  to  develop  and  deliver  a  baseline 
system  first  and  deliver  subsequent  subsystems  at  a 
later  date.  A  baseline  system  is  a  system  which 


performs  some  set  of  useful  (and  satisfactory)  func¬ 
tions  but  which  at  initial  delivery  does  not  perform 
functions  which  are  considered  less  critical  to  the 
maintenance  organization.  If  that  baseline  system 
could  be  determined,  it  might  not  only  help  users  in 
their  acceptance  of  the  system,  but  it  could  also  allow 
the  basic  system,  with  no  shortcuts  in  design,  to  be 
delivered  in  considerably  less  time  than  that  required 
for  the  whole  system. 

Besides  lessening  the  impacts  of  a  new  system 
on  the  end  user  and  shortening  initial  development 
time,  such  a  baseline  system  offers  several  other 
advantages.  If,  during  implementation  testing,  the 
system  were  found  to  be  unworkable  for  some  reason, 
wasted  resources  would  be  limited  to  those  of  a  basic, 
no-frills  development.  In  addition,  subsequent 
subsystems  could  be  developed  and  delivered  while 
taking  advantage  of  lessons  learned  from  previous 
subsystems . 

If  a  baseline  system  for  NALCOMIS/OMA  is  to  be 
built,  then  developers  will  have  to  answer  several 
questions  in  order  to  determine  the  most  appropriate 
subsystems  for  the  baseline  system: 

1)  Which  modules  must  be  built  first?  This  would 
include  any  modules  which  are  necessary  for  the 
existence  of  the  system. 

2)  Which  modules  are  dependent  upon  or  depend  on 
other  existing  modules? 


3)  Which  modules  do  ve  strongly  desire  to  include  in 
our  first  version  of  NALCOMIS/OMA? 


Parnas  [Ref.  24 :p.  312]  says  that  "one  first 
searches  for  the  minimal  subset  that  might  conceivably 
perform  a  useful  service  and  then  searches  for  a  set  of 
minimal  Increments  to  the  system. "  He  also  points  out 
that 

the  identification  of  the  possible  subsets  is  part  of 
identifying  the  requirements ... [This  is]  especially 
Important  to  government  officials  who  purchase 
software ...  they  are  forbidden  by  law  to  tell  the 
contractor  how  to  perform  his  Job.  They  may  tell  him 
what  they  require  but  not  how  to  build  it.  Fortu¬ 
nately,  the  availability  of  subsets  may  be  construed 
as  an  operational  property  of  the  software. 

Although  a  purely  skeletal  system  might  not  be 

very  useful  to  OMAs ,  building  a  NALCOMIS/OMA  which 

would  perform  the  most  basic,  but  effective,  functions 

would  be  useful.  Parnas  even  states  that  while  the 

minimal  subset  is  useful,  "it  is  usually  not  worth 

building  by  itself.”  What  NALCOMIS  must  be  is  a 

foundation  system  which  can  meet  today's  squadron  needs 

effectively  and  be  further  built  upon  as  those  needs 

change  and  even  Increase. 

4.  Making  NALCOMIS  Effective 

Brookes  [Ref.  16:p.  5]  identifies  five  attrib¬ 
utes  which  an  information  system  must  possess  to  be 
truly  effective: 

Decision-oriented  reporting--meaning  that  output  from 
the  system  is  designed  to  facilitate  decision  making 
by  those  persons  who  receive  the  output. 


Effective  processing  of  the  data — Indicating  that  the 
checks  and  controls  on  input  and  output  are  appro¬ 
priate,  system  timing  is  meaningful  in  the  context  of 
the  application,  and  the  utilization  of  the  hardware 
and  software  environment  is  efficient. 

Effective  management  of  the  data--e.g.,  requiring 
attention  to  be  paid  to:  the  timing  of  file  updates, 
the  accuracy  of  input  data,  controlled  redundancy, 
the  maintenance  of  integrity  once  data  are  stored 
within  the  system,  the  security  requirements  while 
the  data  are  being  used  and  on  disposal,  and  appro¬ 
priate  back-up  facilities. 

Adequate  flexibility — i.e.,  it  is  possible  to  meet 
changing  needs  of  the  organization  because  the  system 
can  be  updated  as  new  computing  technology  becomes 
available,  and  can  adapt  to  changes  in  the  behav¬ 
ioural  characteristics  of  those  persons  associated 
with  it. 

A  satisfying  user  environment — those  responsible  for 
the  system's  design  make  sure  that  the  machine- 
people  Interfaces  are  appropriate  for  the  tasks 
involved. 

That  NALCOMIS/OMA  should  possess  these  attri¬ 
butes,  in  addition  to  performing  some  set  of  basic 
useful  services,  is  in  keeping  with  what  was  said 
earlier  in  this  chapter.  NALCOMIS/OMA  should  "make  a 
major  Impact  on  a  key  area  associated  with  the  success 
of  the  business''  [Ref.  16:p.  98]--and  at  the  OMA,  that 
business  is  providing  mission  capable  aircraft.  In 
order  to  make  a  sufficient  Impact  on  the  mission 
capability  rates,  the  effectiveness  of  NALCOMIS/OMA  is 
key. 


5 .  Analyzing  Current  Plans 

Will  NALCOMIS/OMA,  as  currently  planned,  prove 


to  be  an  effective  system  for  improving  mission 


capability  at  the  squadron  level?  Nov  that  ve  have 
Identified  some  of  the  characteristics  that  it  must 
possess  to  do  so,  how  can  ve  decide  vhether  or  not 
these  current  plans  are  adequate? 

Since  no  computerized  system  exists  at  the 
organizational  level.  It  could  be  very  difficult  to 
prove  or  disprove  the  adequacy  of  these  current  plans. 
But  there  Is  one  possible  source  vhich  might  help  In 
such  an  analysis — NALCOMIS  Phase  II. 

As  stated  previously,  many  of  the  functions 
performed  at  the  OMA  are  also  performed  at  the  Interme¬ 
diate  Maintenance  Activity  as  veil.  Vhlle  there  are 
Inherent  differences,  such  as  schedule  pressures,  vork 
environment,  etc.,  there  are  enough  similarities  to 
make  such  a  comparison  useful. 

Although  the  Phase  II  system  Is  still  being 
Introduced  to  the  fleet,  testing  of  the  system  softvare 
has  been  going  on  since  as  early  as  February  1986.  In 
addition,  "prototype  operations  commenced  In  August 
1986."  [Ref.  6]  There  are,  therefore,  personnel  vho 
have  gained  some  experience  vlth  the  Phase  II  system. 

The  next  chapter  contains  a  summary  of  lnter- 
vievs  vlth  some  of  these  Individuals.  Those  lnter- 
vleved  vere  also  quite  knovledgeable  vlth  respect  to 
organizational  level  maintenance  procedures  and,  as  a 
result,  qualified  to  evaluate  some  of  the  Phase  II 


features  In  terns  of  the  OMA.  These  interview  results 
will  later  be  used  in  our  attempt  to  reveal  some  of  the 
strengths  and  weaknesses  of  current  plans. 

0.  SUMMARY 

Many  decisions  face  those  Involved  in  the  manage¬ 
ment  and  development  of  NALCOMIS/OMA.  Some  of  the 
Issues  associated  with  the  following  three  of  these 
decisions  have  been  discussed  in  this  chapter: 

1 )  How  can  NALCOMIS  provide  management  support  to 
squadron  maintenance  managers? 

2)  What  can  NALCOMIS  do  at  the  squadron  level  to 
Improve  mission  capability? 

3)  Should  NALCOMIS/OMA  be  further  developed  or  should 
NOS  be  expanded  to  meet  the  needs  of  the  OMA? 

If  NALCOMIS  is  to  adequately  support  squadron 
maintenance  managers,  it  must  provide,  in  a  timely 
fashion,  information  that  is  useful  in  making  deci¬ 
sions.  But  different  types  of  decisions  are  made 
throughout  the  chain  of  command. 

The  types  of  decisions  made  in  an  organization  can 
be  classified  as  either  strategic  planning,  managerial 
control,  or  operational  control  decisions  [Ref.  21 :p. 
29].  Within  the  OMA  the  decisions  are  primarily  of  the 
managerial  control  and  operational  control  types. 

Managerial  control  decisions,  which  occur  most 
predominantly  between  the  Maintenance  Officer  and 
Division  Officer  levels  of  management,  "deal  with  the 


use  of  resources  In  the  organization  and  often  Involve 
personnel  or  financial  problems. N  Some  of  these 
decisions  require  detailed,  real-time  information, 
while  others  require  less  timely,  summary  information. 

Operational  control  decisions,  on  the  other  hand, 
"deal  with  the  day-to-day  problems  that  affect  the 
operation  of  [the  squadron]."  These  decisions  usually 
require  detailed  information  which  is  closer  to  real¬ 
time. 

NALCOMIS  primarily  supports  reporting  of  informa¬ 
tion  to  higher  levels  of  authority.  Since  this 
information  is  often  of  limited  value  to  squadron 
managers,  and  because  current  plans  for  NALCOMIS/OMA 
will  not  allow  managers  to  create  customized  reports 
[Ref.  10],  some  other  feature  of  the  system  must  allow 
decision  makers  fast,  easy  access  to  the  information 
which  is  needed.  If  customized  reports  cannot  be 
provided,  then  the  on-line  retrieval  of  this  informa¬ 
tion  must  be  made  available. 

NALCOMIS/OMA  will  attempt  to  Improve  mission 
capability  through  "more  accurate  and  timely  processing 
of  data"  and  by  reducing  "delays  due  to  awaiting 
maintenance  (AWM)  and  awaiting  parts  (AVP)."  [Ref.  3:p. 
3]  There  is  another  factor  which  determines  mission 
capability,  however--worker  productivity.  If 
NALCOMIS/OMA  can  contribute  to  relieving  some  of  the 


administrative  burden  at  lover  levels,  particularly  at 
the  work  center  level,  mission  capability  will  likely 
increase  as  a  result. 

NALCOMIS/OMA,  however,  cannot  significantly 
contribute  to  freeing  workers  from  administrative 
burden  unless  It  provides  a  faster  means  of  collecting, 
recording,  and  validating  data  than  the  current  paper 
system.  If  work  center  personnel  must  deal  with  a 
cumbersome,  time  consuming  system  of  data  collection, 
then  they  will  be  less  able  to  contribute  to  Improved 
mission  capability  by  spending  more  time  repairing 
aircraft  discrepancies. 

Finally,  five  attributes  required  for  an  effective 
Information  system  were  Identified  [Ref.  16:p.  5]: 

1)  Decision-oriented  reporting. 

2)  Effective  processing  of  the  data. 

3)  Effective  management  of  the  data. 

4)  Adequate  flexibility. 

5)  A  satisfying  user  environment. 

In  the  following  chapters,  these  five  attributes  will 
become  the  basis  for  analyzing  the  current  plans  for 
NALCOMIS/OMA.  After  presenting  the  results  of  Inter¬ 
views  with  NALCOMIS  Phase  II  system  users  and  other 
organizational  level  maintenance  managers,  the  current 
plans  will  be  evaluated  to  try  and  determine  just  how 
effective  NALCOMIS/OMA  will  be  at  meeting  its  objectives. 


V.  USER  CONCERNS 


The  previous  chapter  Identified  some  of  the 
characteristics  that  NALCOMIS/OMA  must  possess  In  order 
to  be  an  effective  Information  system  and  contribute 
toward  Improved  mission  capability.  It  Is  easy  to 
evaluate  a  system  which  has  already  been  built.  But 
since  we  are  trying  to  determine  beforehand  whether  or 
not  NALCOMIS/OMA  will  possess  those  characteristics, 
the  evaluation  becomes  more  difficult. 

Although  NALCOMIS/OMA  has  not  yet  been  built  and, 
consequently,  there  are  no  experienced  NALCOMIS/OMA 
users,  there  Is  one  group  of  users  that  might  prove 
very  helpful — Phase  II  users.  As  previously  mentioned. 
Phase  II  1 8  currently  being  Introduced  to  the  fleet. 

As  a  result,  there  are  personnel  who  have  gained 
experience  with  the  system  during  evaluation  and 
testing. 

Since  many  of  the  functions  performed  at  the 
Intermediate  Maintenance  Activity  (IMA)  are  similar  to 
those  performed  at  the  OMA,  some  of  the  Phase  II  users 
were  Interviewed  with  the  hope  of  gaining  an  under¬ 
standing  of  the  functions  which  will  be  Included  in 
NALCOMIS/OMA.  The  users  who  were  interviewed  were 
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especially  qualified  since  they  also  had  extensive 
experience  In  organizational  level  maintenance. 

This  chapter  contains  the  results  of  these  Inter¬ 
views.  After  providing  a  description  of  the  users  and 
the  circumstances  under  which  the  Interviews  were 
conducted,  a  summary  of  the  results  will  be  presented 
by  specific  problem  area.  Later,  In  chapter  VIII, 
these  results  will  be  used  to  determine  some  of  the 
strengths  and  weaknesses  of  current  plans  for 
NALCOMIS/OMA. 

A.  THE  INTERVIEWS 

A  three  day  research  trip  to  NAVMASSO  (Norfolk, 
Virginia)  In  October  1987  provided  valuable  background 
Information  on  NALCOMIS/OMA.  Since  the  trip  was 
limited  to  such  a  short  period  of  time,  however,  very 
little  time  was  available  for  conducting  Interviews 
with  Phase  II  users.  Most  of  the  available  time  was 
spent  researching  current  Phase  III  documents  and 
talking  with  personnel  who  were  (and  had  been)  Involved 
with  Phase  III  plans. 

Interviews  were  conducted  with  users  of  the  Phase 
II  system  for  two  main  reasons.  First,  it  was  hoped 
that  by  gaining  knowledge  of  how  the  Phase  II  system 
worked,  some  knowledge  of  NALCOMIS/OMA  would  also  be 
gained.  The  second  reason  was  to  identify  some  of  the 


potential  problems  that  exist  in  current  plans  for 
automating  the  OMA. 

Ms.  Nancy  White,  head  of  the  Systems  Integration 
and  Documentation  Division  at  NAVMASSO,  set  up  the 
interviews.  She  was  asked  to  provide  the  most  know¬ 
ledgeable  persons  available  who  1)  had  used  the  Phase 
II  system,  2)  had  extensive  experience  in  organiza¬ 
tional  maintenance,  and  3)  could  best  answer  questions 
about  potential  problems  that  might  be  encountered  at 
the  OMA. 

1 .  Profiles  of  the  Users  Interviewed 

There  were  three  Phase  II  users  who  best 
qualified  for  the  interviews.  The  following  provides  a 
profile  of  those  interviewed  at  NAVMASSO: 

USER  A 
Rate:  E-7 

Aviation  maintenance  experience:  5  years  OMA;  7  years 
as  a  work  center  supervisor  at  both  OMA  and  IMA;  1 
year  experience  as  a  maintenance  controller 

System  experience:  1  year  Phase  II;  approximately  60 
hours  experience  on  the  contractor's  Phase  III 
prototype 

USER  B 

Rate :  E-7 

Aviation  maintenance  experience:  9  years  OMA;  4  years 
IMA  including  work  center  supervisor;  1  year  in 
Production  Control 

System  experience:  1  year  Phase  II  testing  and 
evaluation 


USER  C 
Rate:  E-7 

Aviation  maintenance  experience:  14  years  OMA 
including  9  years  as  work  center  supervisor,  1  year 
as  a  QAR,  and  3  months  as  maintenance  controller 

System  experience:  7  months  Phase  II  testing  and 
evaluation:  approximately  60  hours  experience  on  the 
contractor's  Phase  III  prototype 

In  addition  to  these  Interviews,  a  fourth  user 
was  recommended  by  the  above  three  as  having  excep¬ 
tional  knowledge  about  the  Phase  II  system.  Because 
this  user  was  assigned  to  MAG-14,  MCAS  Cherry  Point,  N. 
C.,  It  was  Impossible  to  Interview  him  In  person. 
Telephone  Interviews,  however,  were  conducted  with  this 
user.  His  profile  Is  given  below: 

USER  D 
Rate:  E-7 

Aviation  maintenance  experience:  5  years  OMA;  3  years 
IMA 

System  experience:  continuous  Phase  II  experience 
from  May  1986  to  present 

2 .  The  Nature  of  the  Interviews 

It  was  explained  to  each  subject  that  the 
purpose  of  the  Interviews  was  to  learn  how  the  Phase  II 
system  worked.  Additionally,  users  were  told  that, 
through  the  similarities  between  the  Phase  II  and  Phase 
III  systems.  It  was  hoped  that  some  Insight  might  be 
gained  as  to  how  NALC0MIS/0MA  might  serve  to  improve 
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mission  capability  and  provide  management  support  at 
the  OMA. 

Those  interviewed  were  asked  open  ended 
questions.  For  example,  each  was  asked  to  describe  how 
NALCOMIS  Phase  II  is  used,  how  it  compared  with  the 
current  paper  system,  and  what  major  problems,  if  any, 
they  saw  in  the  system.  Any  responses  that  seemed 
especially  surprising  were  followed  up  with  more 
specific  questions. 

In  the  months  following  the  initial  interviews, 
follow-up  interviews  were  conducted  by  telephone. 

These  follow-up  interviews  Included  questions  Intended 
to  clarify  earlier  discussions,  answer  new  questions, 
and  verify  earlier  statements  by  those  interviewed. 

B.  RESULTS  OF  THE  INTERVIEWS 

The  interviews  revealed  a  number  of  common  concerns 
among  the  users  of  the  Phase  II  system.  Each  user, 
fully  aware  that  the  research  was  being  conducted  in 
the  area  of  NALCOMIS/OMA,  discussed  only  those  func¬ 
tions  which  were  common  to  both  Phase  II  and  the 
planned  Phase  III  systems.  The  results  of  these 
interviews,  categorized  by  problem  area,  is  contained 
below. 

1 .  Users*  Expectations 

Users  A,  B,  and  D  each  Independently  stated 


that  the  user  must  know  and  understand  the  NAMP.  While 


maintenance  personnel  (including  managers)  are  expected 
to  know  how  the  NAMP  operates,  many  do  not.  Often, 
maintenance  personnel  fall  to  distinguish  local 
procedures  from  those  which  are  directed  by  the  NAMP. 

Since  NALCOMIS  is  designed  with  the  NAMP  in 
mind,  there  are  only  limited  functions  that  will  be 
performed.  Therefore,  a  thorough  understanding  of  NAMP 
procedures  and  knowledge  of  what  NALCOMIS  is  capable  of 
doing  is  necessary  in  order  to  prevent  frustrations 
within  the  organization.  Dickson  [Ref.  25:p.  4]  refers 
to  this  difference  between  "what  is  expected  and  what 
occurs"  as  the  "expectations  gap." 

An  understanding  of  the  NAMP  and  current  manual 
procedures  is  also  necessary  in  the  event  that  NALCOMIS 
breaks  down.  Even  if  the  highest  degree  of  reliability 
is  achieved  by  NALCOMIS  hardware  and  software,  the 
organization  must  be  prepared  to  revert  to  a  paper 
system,  being  fully  aware  of  procedures,  information 
flows,  and  how  to  properly  fill  out  paper  forms.  These 
users  felt  that,  in  order  to  be  ready  to  shift  to  a 
contingency  mode  at  any  time,  a  VIDS  board  (discussed 
in  Chapter  VI)  will  have  to  be  maintained  and  updated 
at  all  times.  User  B  felt  that  it  might  be  necessary 
to  maintain  a  current  VIDS  board  not  only  within 
Maintenance  Control,  but  within  each  work  center,  as 


2 .  Ease  of  Use 


Although  screens  and  conversations  are  designed 
with  ease  of  use  in  mind.  User  B  felt  that  learning  to 
use  NALCOMIS  may  present  a  problem  to  new  users.  Users 
A,  B,  and  D  doubted  that,  even  after  NALCOMIS/OMA  has 
been  delivered  and  in  use  for  a  reasonable  period  of 
time,  it  will  be  relatively  easy  to  use. 

The  period  of  time  immediately  following  fleet 
delivery  will,  of  course,  be  the  most  frustrating,  with 
the  entire  maintenance  organization  learning  and 
adapting  to  the  new  system.  The  high  pressure  environ¬ 
ment  of  aviation  maintenance,  coupled  with  new  proce¬ 
dures,  will  prove  most  challenging.  User  A,  although 
experienced  with  the  Phase  II  system,  was  observed 
using  paper  aids  in  parallel  with  the  system.  He  used 
a  list  of  codes,  for  example,  to  guide  him  through  the 
necessary  conversations. 

User  D  said  that  "lots  of  printouts  are  being 
used  by  people  utilizing  the  system."  He  cited  lists 
of  codes  (e.g.,  VIDS/MAF  codes.  Job  status  codes)  as 
being  used  quite  often.  Most  alarming,  however,  was 
his  statement  that  personnel  are  using  printouts 
"because  going  to  the  appropriate  menu  screens  is  Just 
too  much  time  and  trouble." 


3 .  Will  the  Automated  VIDS/MAF  Really  Save  Time? 

Each  individual  user  of  the  system  must  slgn-on 
with  his  own  unique  password.  If  Petty  Officer  Smith 
is  signed-on  and  currently  working  on  a  task,  what 
happens  if  he  is  distracted  momentarily,  for  example, 
to  answer  the  telephone?  Another  user.  Petty  Officer 
Jones,  meanwhile,  enters  the  work  center  with  some 
urgent  task,  breaks  Smith’s  connection,  and  signs  on 
himself.  Jones  is  now  finished  with  his  task  and  then 
Smith  returns.  According  to  User  B,  Smith  must  now 
slgn-on  and  re-enter  the  lost  data  before  completing 
his  task. 

Users  B  and  D  stated  that  a  queuing  problem  can 
also  potentially  develop  any  time  more  than  one  user 
within  the  work  center  needs  access  to  the  system  at 
"  the  same  time.  Other  than  finding  an  available 

terminal  in  another  work  center,  the  only  alternative 
available  to  users  in  the  queue  is  to  wait  on  the 
current  user  to  finish.  With  the  paper  VIDS/MAF 
system,  however,  many  different  workers  are  able  to 
pull  the  appropriate  MAFs  from  the  VIDS  board,  complete 
the  paperwork,  and  move  on  to  the  next  task. 

User  D,  the  interviewee  with  the  most  NALCOMIS 


Phase  II  operational  experience,  noted  that  queuing  is 
"our  biggest  problem.  Avionics  is  our  largest  work 


center,  and,  therefore.  Is  moat  likely  to  have  numerous 
personnel  trying  to  update  a  MAF  at  the  same  time." 

Even  with  the  Individual  user,  it  is  often  much 
faster  to  pull  a  paper  MAF,  make  a  pen  entry,  and 
replace  the  MAF.  With  an  automated  MAF,  however,  it  is 
necessary  to  take  a  certain  amount  of  time  to  log  onto 
the  system  and  go  through  the  appropriate  conversa¬ 
tions  . 

User  A  stated  that  the  maintenance  control 
manager  (e.g. ,  Maintenance  CPO )  is  constantly  looking 
at  the  master  VIDS  hoard  to  make  his  decisions.  He  has 
a  major  concern  with  the  way  In  which  the  system 
presents  data  on  screen.  He  doubts  whether  the  big 
picture  of  maintenance  can  be  as  easily  drawn  from 
screen  outputs  as  Is  currently  done  with  the  VIDS 
board.  Perhaps  managers  will  eventually  learn  how  to 
best  extract  the  Information  that  Is  needed,  but  he 
felt  that,  as  currently  designed,  much  more  effort  Is 
required  with  the  automated  system  than  with  the  visual 
paper  system. 

User  A  felt  that  the  extra  effort  required  to 
gain  an  overall  view  of  the  maintenance  situation  might 
require  more  personnel  In  Maintenance  Control.  He  also 
expressed  doubts  that  one  terminal  within  Maintenance 
Control  would  be  adequate  since  the  maintenance  effort 
Is  so  dependent  on  the  VIDS  board  for  decision  making. 


He  thought  that  as  many  as  three  terminals  might  be 
required  to  allow  Maintenance  Control  to  keep  up  with 
all  of  the  Information  necessary  to  coordinate  the 
maintenance  effort:  one  terminal  to  keep  track  of  and 
make  Inquiries  regarding  the  present  maintenance 
situation;  one  for  sending  mailbox  messages  (l.e., 
concerning  MAF  control  numbers,  priority  messages, 
etc.);  and  one  for  use  by  the  Logs  and  Records  person¬ 
nel.  A  fourth  terminal  might  even  be  required  If  Naval 
Aircraft  Flight  Records  (Yellow  Sheets)  are  used  In  the 
maintenance  control  area  (as  is  done  with  the  current 
paper  system). 

4 .  Ignoring  the  System 

As  mentioned  earlier,  there  are  many  Instances 
when  a  paper  MAF  system  might  be  faster  and  require 
considerably  less  effort  than  a  computerized  system. 
Users  A  and  C  were  concerned  that  there  might  be  a  real 
danger  here  that  personnel  will  attempt  to  bypass,  or 
Intentionally  Ignore,  NALCOMIS.  Their  biggest  fear  was 
that  simple  discrepancies  might  not  be  written  up  at 
all . 

The  aviation  maintenance  environment  Is,  most 
often,  one  filled  with  heavy  schedule  pressures.  Extra 
pressure  might  be  added  to  the  situation  when  one  Is 
faced  with  the  possibility  of  missing  an  aircraft 


launch  because  NALCOMIS  Is  slow  or  momentarily  inacces¬ 
sible  . 

User  A  Illustrated  the  effects  of  such  pres¬ 
sures  using  the  following  example.  Consider  what  might 
happen  when  the  determination  Is  made,  just  prior  to 
scheduled  takeoff,  that  drop  tanks  are  required  on  an 
aircraft.  If  the  worker,  already  under  pressure  to  et 
the  launch  commitment.  Is  unable  to  find  an  available 
terminal,  he  might  choose  to  do  the  job  without  using 
NALCOMIS  at  all.  He  may  Ignore  the  system  rather  than 
wait  on  an  available  terminal,  go  through  all  of  the 
necessary  conversations,  and  finally  complete  the  MAF — 
and  miss  the  scheduled  takeoff  time. 

Besides  documenting  all  of  the  work  done  on  an 
aircraft,  the  MAF  serves  to  ensure  that  all  of  the 
proper  maintenance  has  been  performed  so  that  an 
aircraft  Is  safe  for  flight.  Even  the  simplest 
maintenance  tasks  require  that  qualified  personnel 
check  the  quality  of  work  performed.  If  NALCOMIS  were 
ever  Ignored  by  maintenance  personnel ,  safety  could  be 
jeopardized . 

5 .  Security 

Further  concern  that  people  might  Ignore  or 
Improperly  use  NALCOMIS  dealt  with  security.  Fears 
were  expressed  by  Users  B  and  C  that,  for  example, 
passwords  would  freely  be  handed  from  one  person  to 
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another  for  the  sake  of  convenience.  User  B  said  that 
he  could  envision  a  situation  In  which  "a  list  of 
passwords  Is  given  to  one  person."  For  instance,  a 
work  center  supervisor  might  obtain  the  password  of  a 
Collateral  Duty  Inspector  and  Quality  Assurance 
Representative  (QAR),  In  order  to  quickly  and  conve¬ 
niently  sign  off  a  MAF. 

An  additional  security  concern  was  that  If 
users  were  allowed  to  choose  their  own  passwords,  other 
personnel  might  easily  access  the  system  under  a  false 
Identity.  If  a  QAR  chose  something  easy  to  remember 
for  his  password,  say  a  nickname  or  his  birth  date, 
then  someone  else  with  knowledge  of  the  QAR ’ s  account 
(or  access  to  that  knowledge)  might  compromise  the 
system.  User  A  suggested  that  a  random  password 
generator  could  be  used  to  assign  passwords  rather  than 
having  personnel  choose  their  own. 

User  C  said  that  the  possibility  of  system 
compromise  should  be  a  cause  for  alarm  among  those 
responsible  for  safety  of  flight  items.  After  the 
occurrence  of  an  aircraft  mishap,  what  are  the  legal 
Implications  of  the  new  system?  It  might  become  very 
difficult  to  prove  or  disprove  claims  by  an  Individual 
that  his  password  had  been  compromised.  A  type  of 
electronic  forgery,  therefore,  could  become  a  very  real 
threat  and  an  Issue  difficult  to  resolve.  Before  a 


similar  situation  arises,  it  might  serve  well  to 
discuss  such  Issues  with  the  Naval  Aviation  Safety 
Center. 

6.  Purging  of  Data 

The  Quality  Assurance  division  of  the  OMA,  for 
tracking  and  analysis  purposes,  often  relies  on 
historical  data.  What  will  happen  when  QA  needs  data 
that  has  been  purged  from  the  data  base?  User  A 
expressed  concern  that  retrieving  the  data  necessary 
for  such  analyses  may  be  a  very  time-consuming  process. 
Will  the  periodic  purging  of  the  NALCOMIS  data  base 
mean  that  retrieval  of  such  data  will  seem  not  worth 
the  effort  to  QA  personnel?  User  A  felt  that,  at  best, 
QA  will  keep  hardcopy  printouts  and  continue  its 
analysis  efforts  manually. 

7.  Management  Support 

There  was  a  general  feeling  among  the  users 
that  the  system  does  not  provide  much  management 
information.  Again,  this  depends  upon  what  data  the 
individual  uses  to  arrive  at  his  decisions.  But  User  A 
felt  that  some  of  the  subsystems  could  be  cut  down  in 


size,  quite  possibly  in  order  to  make  room  for  more 
management  information.  He  perceived  NALCOMIS  as 
containing  double  documentation  (often,  the  same  data 
existing  both  electronically  and  in  paper  form)  and 
unnecessary  data. 


User  A  also  stated  that  some  NAMP  programs, 
such  as  the  Hydraulic  Contamination  Control  Program  and 
Oil  Analysis  programs,  for  example,  must  still  be  done 
manually.  Similarly,  there  appears  to  be  little 
provision  for  Quality  Assurance  tracking  and  trend 
analysis,  which  might  take  priority,  In  his  opinion, 
over  existing  Technical  Publications  provisions. 

8.  Other  Concerns 

A  problem  of  less  critical  nature,  but  still  a 
genuine  concern,  was  expressed  by  User  A.  Suppose,  for 
Instance,  that  a  portion  of  the  squadron  goes  on 
detachment  from  the  1st  through  the  29th  of  the  month. 
The  detachment,  using  a  paper  MAF  system,  returns  with 
a  high  volume  of  data  (on  paper  VIDS/MAFs)  which  must 
be  processed  in  a  very  short  period  of  time  (for  end  of 
the  month  reporting).  Many  hours  of  additional  (and 
duplicative)  effort  would  be  required  for  necessary, 
historical  purposes. 

With  the  exception  of  planned  down  time,  each 
of  the  users  felt  that  the  Honeywell  hardware  was  very 
reliable.  Prevailing,  however,  was  the  feeling  that 
response  time  was  a  "bit  slow."  In  addition.  User  B 
said  that  printing  hardcopy  documents  on  some  of  the 
available  printers  seemed  "very  slow." 


C.  SUMMARY 

The  concepts  vnich  are  encompassed  in  current  plans 
for  NALCOMIS/OMA  are  seen  by  present  and  potential 
future  users  as  being  both  necessary  and  highly 
desirable.  Automation  and  the  resulting  changes  In 
procedures  are  viewed  as  worth  the  effort.  There  was  a 
consensus  among  the  Phase  II  users  and  the  squadron 
maintenance  managers  who  were  interviewed  that  an 
automated  maintenance  system  Is  long  overdue. 

While  the  Phase  II  users  who  were  Interviewed  have 
been  Intimately  Involved  with  development  and  testing 
of  the  system,  and,  therefore,  will  be  more  knowledge¬ 
able  about  NALCOMIS  than  ultimate  fleet  users,  there  Is 
no  reason  to  expect  that  the  system  cannot  be  accepted 
by  the  fleet  once  these  and  other  critical  management 
Issues  are  adequately  resolved. 

While  Intended  as  only  a  brief  synopsis  of  Inter¬ 
views  with  Phase  II  users,  this  discussion  has  hope¬ 
fully  provided  some  Insight  as  to  the  nature  of  user- 
manager  concerns  that  face  the  NALCOMIS/OMA.  Although 
criticisms  exist,  users  appeared  patient  and  willing  to 
work  with  the  NALCOMIS  until  Improvements  are  made. 
While  there  Is  no  way  to  completely  satisfy  every  user 
and  manager  at  the  OMA,  many  of  the  problems  discussed 
(and  others  not  discovered  through  these  Interviews) 
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will  require  attention,  preferably  prior  to  final 
system  delivery. 
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VI.  NAMP  PROCEDURES 


As  stated  In  the  previous  chapter,  squadron 
personnel  do  not  always  have  a  clear  under standing  of 
the  differences  between  NAMP  and  local  procedures. 

Those  with  less  knowledge  about  the  NAMP  may  know  how 
to  accomplish  their  jobs  correctly,  but  do  not  neces¬ 
sarily  know  when  they  are  performing  a  task  In  accor¬ 
dance  with  local,  rather  than  NAMP,  procedures. 

The  purpose  of  this  chapter  Is  to  explain  NAMP 
procedures  for  the  collection  and  display  of  data 
within  the  OMA.  Since  a  complete  explanation  of  all 
NAMP  procedures  Is  well  beyond  the  scope  of  this 
thesis,  the  discussion  will  focus  on  the  Visual 
Information  Display  System/Maintenance  Action  Form 
(VIDS/MAF).  The  largest  amount  of  data  within  the 
squadron  Is  collected  on  this  form  [Ref.  7:p.  11-3]. 

After  providing  an  explanation  of  the  flow  of  the 
VIDS/MAF  within  the  squadron,  several  of  the  potential 
benefits  of  changing  from  a  paper  to  automated,  on-line 
VIDS/MAF  are  Identified  and  briefly  discussed. 

A.  CONTROLLING  MAINTENANCE 

The  NAMP  provides  maintenance  managers  with 
standardized  procedures  which  help  them  efficiently 
manage  their  resources.  To  assist  in  doing  so,  the 


Visual  Information  Display  System  (VIDS)  was  estab¬ 
lished  to  provide  managers  with  the  information 
necessary  to  control  those  resources  while  minimizing 
paperwork. 

The  VIDS  Is  a  management  tool  that  provides  a  graphic 
display  of  vital,  up-to-date  Information  on  a 
continuing  basis.  The  system  correlates  all  aircraft 
status  Information,  particularly  NMCS/PMCS,  flyable 
discrepancies,  and  assigns  a  relative  Importance  to 
each  item.  The  ability  to  review  the  overall 
situation  and  determine  what  resources  are  available 
enables  the  MO  and  MMCO,  or  supervisor,  to  carry  out 
their  duties  more  effectively  and  efficiently.  [Ref. 
7:p.  6-2] 

VIDS  boards  are  enlarged  cardex  type  pockets  for 
the  visual  display  of  weapon  system  status.  Each 
pocket  Is  overlapped  by  the  one  above  so  that  approxi¬ 
mately  a  3/8-inch  strip  Is  visible  at  the  bottom  of  the 
pockets  [Ref.  7:p.  6-3].  While  the  exact  set-up  of  the 
VIDS  board  Is  left  to  the  discretion  of  the  individual 
organization,  the  NAMP  does  require  that  IN  WORK,  AWM 
(awaiting  maintenance),  and  AWP  (awaiting  parts)  status 
be  displayed  by  aircraft  bureau/side  number  [Ref.  7:p. 
6-3].  Typical  VIDS  board  layouts  found  In  a  Mainte¬ 
nance  Control  are  illustrated  in  Figure  2  [Ref.  7:p.  6- 
»]. 

"That  portion  of  the  maintenance  organization’s 
workload  devoted  to  repair.  Technical  Directive 
compliance,  and  periodlc/condltlonal  Inspections  Is  the 
area  In  which  there  is  the  greatest  requirement  for 
data  in  depth."  [Ref.  7:p.  11-3]  This  in-depth  data  is 
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O-Ltwl  Maintenance  Control  Board  (Side  No».  and  W/Ct> 

Typical  0-Level  Maintenance  Control  VIDS  Boards 

Figure  2 


collected  during  the  maintenance  process  on  the  Visual 
Information  Display  System/Maintenance  Action  Form,  or 
VIDS/MAF  (Figure  3).  It  is  the  VIDS/MAF  which  is 
placed  in  the  card  slots  on  the  VIDS  board.  By  placing 
the  VIDS/MAF  on  the  VIDS  board  under  the  appropriate 
aircraft,  work  center,  and  status  (i.e.,  IN  WORK,  AWM, 
AWP ) ,  maintenance  managers  can  obtain  an  overall  view 
of  the  maintenance  situation  In  order  to  make  decisions 
as  to  how  best  employ  their  resources.  By  flagging 
each  active  VIDS/MAF  with  colored  fillers  while  on  the 
board,  the  manager  can  also  see  at  a  glance  which 
discrepancies  place  the  aircraft  in  either  a  Partial 
Mission  Capable  or  Not  Mission  Capable  status. 

The  VIDS/MAF  (Figure  3)  is  a  five  part  document. 
Each  copy  is  identical  to  the  other  with  the  exception 
of  copy  2,  which  only  contains  that  information  found 
on  the  lower  half  of  the  MAF.  After  the  MAF  is 
initiated  and  Maintenance  Control  has  determined  what 
sort  of  action  is  required,  the  MAF  is  separated  and 
copies  distributed  as  appropriate.  A  more  detailed 
explanation  of  MAF  distribution  follows  in  the  next 
section. 

In  addition  to  the  master  VIDS  board  found  in 
Maintenance  Control,  each  work  center  is  also  required 
to  maintain  a  VIDS  board  for  those  MAFs  which  pertain 
to  that  work  center.  As  with  any  duplication  of  data, 
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The  VIDS/MAF 
Figure  3 

88 


there  exists  a  possibility  that  some  of  the  data 
contained  on  the  work  center  board  Is  lr.  conflict  with 
the  master  VIDS  board.  Therefore*  the  work  center  must 
verify*  on  a  dally  basis,  that  the  Information  con¬ 
tained  on  the  master  board  Is  the  same  as  that  con¬ 
tained  In  the  work  center. 

Maintenance  Control  also  maintains*  for  each 
aircraft*  an  Aircraft  Discrepancy  Book  ( ADB ) .  "The  ADB 
Is  designed  to  provide  maintenance  and  aircrew  person¬ 
nel  with  an  accurate,  comprehensive*  and  chronological 
record  of  flights  and  maintenance  performed  on  a 
specific  aircraft. . .for  at  least  the  last  10  flights" 
[Ref.  7:p.  6-7]  As  will  be  seen*  the  ADB  provides  this 
record  by  containing  VIDS/MAFs  written  against  that 
particular  aircraft.  Those  VIDS/MAFs  contained  In  the 
ADB  must  also  be  verified  against  the  Maintenance 
Control  and  work  center  VIDS  boards  to  ensure  accuracy. 

During  several  visits  to  a  typical  OMA*  maintenance 
managers  estimated  that  somewhere  between  80-9051  of  all 
VIDS/MAFs  were  Initiated  due  to  corrective  maintenance. 
Because  there  are  such  a  large  number  of  different  type 
maintenance  actions  which  are  recorded  on  the  VIDS/MAF* 
and  since  repairs  account  for  such  a  large  percentage 
of  the  organization’s  workload*  the  focus  of  this 
research  was  placed  on  discrepancy  MAFs — those  MAFs 


which  are  Initiated  due  to  a  need  for  corrective 
maintenance  on  an  aircraft. 


B.  DISCREPANCY  VIDS/MAF  FLOW 

Figure  4 ,  taken  directly  from  the  NAMP ,  Vol.  II, 
Illustrates  the  flow  of  the  VIDS/MAF  document  within  an 
O-level  Maintenance  Activity.  The  following  comments, 
derived  from  the  NAMP  and  a  visit  to  an  organizational 
maintenance  activity,  are  numbered  to  correspond  with 
Figure  4  [Ref.  7:p.  6-8]: 

1.  Initiates  VIDS/MAF 


a.  Pilot  or  Other  VIDS/MAF  Initiator 

The  pilot,  or  other  maintenance  person 

discovering  the  discrepancy.  Initiates  a  VIDS/MAF  by 

filling  out  the  following  blocks  of  Information: 

A48,  TYPE  EQUIP— A  four-character  code  that  Identi¬ 
fies  the  end  Item  (e.g.,  aircraft,  engine,  etc.) 
being  repaired. 

A52,  BU/SER  NUMBER — The  serial  number  of  the  item 
being  repaired.  Aircraft,  for  example,  are  assigned 
a  slx-dlglt  number. 

A58,  DISCD — A  single  alpha  character  describing  when 
the  need  for  maintenance  was  discovered. 

DISCREPANCY — A  concise,  written  description  of  the 
discrepancy. 

PILOT/  INITIATOR — The  name  and  rate  (or  rank)  of  the 
Individual  Initiating  the  VIDS/MAF. 

B08  &  B12 ,  RECEIVED  DATE-TIME — Julian  date  and  time 
that  the  MAF  Is  Initiated. 
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b.  MCPO  Assigns  the  Work  Center 

By  reading  or  listening  to  the  description 

of  the  discrepancy  (and,  If  needed,  discussing  it  with 

the  MAF  Initiator),  the  MCPO  decides  which  work  center 

is  responsible  for  the  needed  repair  and  whether  the 

discrepancy  places  the  aircraft  in  a  down  status.  He 

then  appropriately  completes  blocks: 

A19,  WORK  CENTER — A  three-character  code  used  to 
Identify  the  work  center  performing  the  required 
maintenance. 

UP/DOWN — The  appropriate  block  Is  checked  to  indicate 
the  status  of  the  equipment. 

A59 ,  T/M — A  one-character  code  describing  the  type  of 
work  to  be  performed  (e.g.,  scheduled,  unscheduled, 
etc.  ) 

c.  VIDS  Board  Clerk 

The  VIDS  board  clerk  completes  any  further 
required  Information.  One  such  block,  MODEX,  Is  a 
three-digit  number  used  locally  to  Identify  an  Individ¬ 
ual  aircraft.  Modex  Is  also  referred  to  as  the 
aircraft's  side  number. 

The  VIDS  board  clerk  also  assigns  a  Job 

Control  Number  (JCN)  which  uniquely  Identifies  each 

MAF .  The  JCN  Includes  blocks: 

A08,  ORG — A  three-character  code  which  Identifies  the 
organization. 

All,  DAY — The  last  tree  digits  of  the  Julian  date 
which  Identify  the  day  of  the  year. 

A14 ,  SER — A  three-character,  locally  assigned  serial 
number.  By  assigning  serial  numbers  sequentially, 
each  JCN  becomes  a  unique  number. 


The  copies  of  the  VIDS/MAF  are  separated.... 


2.  Copy  3  Retained  on  VIPS  board 

Copy  3  Is  placed  on  the  master  VIDS  board  In 
Maintenance  Control  and  copy  4  Is  placed  In  the 
appropriate  ADB. 

2a.  Copy  2  Is  Delivered  to  QA 

Copy  2  Is  delivered  to  QA  where  It  is  placed  in 
the  trend  book  awaiting  completion  of  the  maintenance 
action. 

3.  Copies  1  and  5 

a.  Work  Center 

Copies  1  &  5  are  sent  to  the  appropriate 
work  center  where  they  are  placed  on  the  work  center 
VIDS  board.  The  work  center  supervisor.  In  examining 
his  VIDS  board,  prioritizes  his  Jobs  according  to  what 
discrepancies  need  to  be  corrected  In  order  to  get  an 
aircraft  up  or  ready  for  the  next  mission.  Maintenance 
Control,  depending  on  the  situation,  may  direct  the 
work  center  supervisor  as  to  which  Jobs  have  the 
highest  priority. 

b.  Work  Center  Supervisor  Assigns  Job 
Then,  considering  such  factors  as  the 

physical  location  of  the  aircraft,  safety  considera¬ 
tions,  and  the  time  available  to  work  on  the  aircraft, 
the  work  center  supervisor  assigns  the  Job  to  a 
qualified  maintenance  man. 
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4 .  Assigned  Job 

The  worker,  as  proceeding  with  the  job,  fills 

out  the  appropriate  data  sections  on  copies  1  and  5: 

ACCUMULATED  WORK  HOURS — Used  to  account  for  man¬ 
hours  spent  on  repairing  the  discrepancy.  Also  used 
to  document  that  an  Inventory  of  tools  has  been 
performed  upon  return  to  the  work  center. 

A22,  WORK  UNIT  CODE — Identifies  the  specific  system, 
subsystem,  or  component  which  Is  being  repaired. 

A29 ,  ACTION  0R6 — A  code  Indicating  the  organization 
accomplishing  the  work. 

A32 ,  TRANS — A  two-digit  code  which  Identifies  the 
type  of  data  being  reported 

A34 ,  MAINT/L — A  single  digit  (1,  2,  or  3)  Indicating 
the  level  of  maintenance  performed. 

A3S,  ACT  TAKEN — A  one-character  code  describing  the 
action  that  has  been  taken  (l.e.,  repair,  remove  and 
reinstall,  etc.) 

A36,  MAL  CODE — Three-character  code  which  Indicates 
the  malfunction  which  caused  the  repair  to  take 
place. 

A39 ,  ITEMS/ P- -The  number  of  Items  processed  (e.g., 
replaced  or  repaired). 

A41,  MAN  HOURS — The  total  number  of  man-hours 
expended  In  order  to  complete  the  repair. 

A45 ,  ELAPSED  M/T — The  total  clock  time  (not  man¬ 
hours)  required  for  the  repair. 

B19  &  B23 ,  IN  WORK  DATE-TIME— The  Julian  date  and 
time  that  work  Is  begun  on  the  discrepancy. 

B30  &  B34 ,  COMPLETED  DATE-TIME- -Julian  date  and  time 
that  the  repair  Is  completed. 

CORRECTIVE  ACTION — A  description  of  the  action  taken 
to  correct  the  discrepancy. 

CORRECTED  BY — Signature  and  rate  of  the  worker  (or 
crew  leader)  performing  the  maintenance. 
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INSPECTED  BY — Signature  and  rate  of  the  Quality 
Assurance  Representative  or  Collateral  Duty  Inspector 
who  Inspects  the  job. 


SUPERVISOR — Signature  and  rate  of  the  work  center 
supervisor.  This  signature  Indicates  that  Quality 
Assurance  and  tool  control  requirements  have  been 
met. 

5.  Document  Requisitioning  of  Parts 

If  parts  need  to  be  ordered,  then  the  worker 
obtains  supply  and  status  Information  from  Material 
Control  and  records  the  Information  on  the  MAF. 

6.  Inserted  on  VIPS  board 

The  VIDS/MAF  Is  placed  under  the  AWP  section  of 
the  VIDS  board  until  the  required  parts  are  received. 

7 .  Upon  Completion  of  Job 

Upon  completion  of  the  job.  the  worker  signs 
off  the  maintenance  action,  obtains  other  signatures 
(l.e.,  CDI .  QAR )  as  required.  The  work  center  supervi¬ 
sor  checks  the  MAF  for  accuracy  and  completeness  and 
forwards  copy  1  back  to  Maintenance  Control . 

8.  Retains  Copy  5 

Copy  S  Is  retained  In  the  work  center  until  the 
Maintenance  Data  Report  (MDR)  containing  that  MAF  Is 
received  from  the  Data  Services  Facility.  Once  that 
copy  has  been  verified  against  the  MDR  to  ensure  that 
the  data  on  each  document  corresponds.  It  Is  destroyed. 
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.  Update  Copies  3  and  4 


a.  VIDS  Board  Clerk 

Once  the  MAF  is  signed  off  by  the  work 
center  supervisor  and  copy  1  Is  returned  to  Maintenance 
Control,  the  VIDS  board  clerk  pulls  copies  3  &  4  from 
the  VIDS  board  and  ADB.  The  VIDS  clerk  then  tran¬ 
scribes  the  following  blocks  from  copy  1  onto  copies  3 
&  4: 

A22 ,  WORK  UNIT  CODE 

A29,  ACTION  ORG 

A32 ,  TRANS 

A34 ,  MAINT/L 

A35 ,  ACT  TAKEN 

A36 ,  MAL  CODE 

A39 ,  ITEMS/P 

A41 ,  MAN  HOURS 

A45 ,  ELAPSED  M/T 

B19  ft  23,  IN  WORK  DATE-TIME 

B30  ft  B34 ,  COMPLETED  DATE-TIME 

CORRECTIVE  ACTION 

CORRECTED  BY 

INSPECTED  BY 

SUPERVISOR 

Copies  3  ft  4  are  then  signed  under  the  MAINT  CONTROL 
block.  Copy  3,  which  now  denotes  a  discrepancy  which 
has  been  corrected.  Is  placed  In  the  ADB  for  the 
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pilot's  review.  Once  ten  flights  have  been  completed 
on  the  aircraft,  copy  3  Is  removed  and  destroyed. 

b.  Logs  and  Records 

Copy  1  Is  then  sent  to  the  Logs  and  Records 

section.  The  Logs  and  Records  clerk  first  checks 

certain  data  blocks  for  accuracy  and  completeness: 

MODEX  and  A52  (Bureau  Number)  are  checked  to  ensure 
that  they  correspond. 

A22  (WORK  UNIT  CODE)  Is  checked  to  ensure  It  contains 
the  correct  number  of  digits. ’ 

A29,  A32,  A34,  A35 ,  A36,  and  A39  are  checked  to 
ensure  completion. 

A41 ,  MAN  HOURS,  and  A45,  ELAPSED  M/T,  are  checked 
against  the  ACCUMULATED  WORK  HOURS  block  for  arithme¬ 
tic  errors. 

A48,  A52,  A58 ,  and  A59  are  checked  for  correctness. 

REPAIR  CYCLE  times  are  checked  to  ensure  they  are 
reasonable. 

c.  Log  Entries  Made 

Next,  the  clerk  decides  whether  or  not  a 
log  entry  Is  required.  If  so,  then  depending  on  the 
type  of  entry  required  by  the  NAMP,  he  uses  the 
appropriate  data  from  the  following  VIDS/MAF  blocks  for 
his  entries  In  the  aircraft  logbook: 

REPAIR  CYCLE  (dates  and  times) 

DISCREPANCY 

A22 ,  WORK  UNIT  CODE 

REMOVED/OLD  ITEM  section  (blocks  E08-E52)--If  a 
repairable  component  has  been  removed  from  an 
aircraft  (or  other  end  Item),  this  section  contains 
data  specific  to  that  component. 
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INSTALLED/NEW  ITEM  section  (blocks  G08-G48)--If  a 
repairable  component  has  been  Installed  on  an 
aircraft  (or  other  end  Item),  this  section  contains 
data  specific  to  that  component. 

The  Logs  and  Records  clerk  then  checks  the  logs  and 

records  blocks  under  the  ENTRIES  REQUIRED  SIGNATURE 

section  and  signs  the  VIDS/MAF.  He  then  forwards  copy 

1  to  the  Analyst  In  QA. 

9a.  Copy  4  Used  by  QA/A 


Copy  4  Is  forwarded  to  QA.  By  matching  this 

copy  with  copy  2,  QA  Is  assured  that  the  discrepancy 

has  been  completed.  It  now  uses  copy  4  to  complete  Its 

collection  of  data  to  be  used  In  trend  analysis.  In 

doing  so,  QA  uses  the  following  blocks: 

A19 ,  WORK  CENTER — A  three-character  code  used  to 
Identify  the  work  center  performing  the  required 
maintenance. 

MODEX — A  three-digit  number  used  locally  to  Identify 
an  Individual  aircraft. 

A52 ,  BU/SER  NUMBER — The  serial  number  of  the  Item 
being  repaired.  Aircraft,  for  example,  are  assigned 
a  slx-dlglt  number. 

DISCREPANCY — A  concise,  written  description  of  the 
discrepancy. 

CORRECTIVE  ACTION — A  description  of  the  action  taken 
to  correct  the  discrepancy. 

A35,  ACT  TAKEN — A  one-character  code  describing  the 
action  that  has  been  taken  (l.e.,  repair,  remove  and 
reinstall,  etc.) 

A36 ,  MAL  CODE — Three-character  code  which  Indicates 
the  malfunction  which  caused  the  repair  to  take 
place . 


PILOT/  INITIATOR — The  name  and  rate  (or  rank)  of  the 
individual  Initiating  the  VIDS/MAF. 

CORRECTED  BY — Name  and  rate  of  the  worker  (or  crew 
leader)  performing  the  maintenance. 

INSPECTED  BY — Name  and  rate  of  the  Quality  Assurance 
Representative  or  Collateral  Duty  Inspector  who 
Inspects  the  Job. 

SUPERVISOR--Name  and  rate  of  the  work  center  super¬ 
visor  . 

All,  DAY — The  last  tree  digits  of  the  Julian  date 
which  Identify  the  day  of  the  year. 

a.  OAR  Receives  and  Checks  Copy  4 

When  copy  4  Is  received,  OA  looks  first  at 

block  A19  to  determine  which  OAR  should  receive  the 

MAF.  That  OAR  then  enters  the  appropriate  data  on  a 

trend  sheet  which  he  uses  to  track  discrepancies  which 

fall  under  his  area  of  expertise.  The  trend  sheet  is 

discussed  In  more  detail  In  the  next  chapter. 

The  QAR  also  checks  the  data  (such  as 

blocks  A35  &  A36)  to  ensure  that  It  Is  consistent  with 

the  discrepancy  and  corrective  action  taken. 

10.  Screened  by  Analysis 

The  QA  Analyst  screens  copy  1  to  ensure  that 
the  MAF  1 s  legible  and  contains  no  errors.  While  some 
errors  escape  the  analyst,  his  job  Is  to  minimize 
errors  before  the  VIDS/MAF  Is  sent  to  the  Data  Services 
Facility  (DSF)  for  processing.  These  copies  are 
typically  delivered  to  the  DSF  at  least  dally,  some¬ 
times  twice  dally. 


11 .  Received  from  DSF 

As  the  DSF  receives  VIDS/MAFs,  operators 
keypunch  all  numbered  Items  from  the  MAF  onto  tape.  A 
second  operator  keypunches  the  same  data  for  verifica¬ 
tion.  Once  a  MAF  Is  completed  It  Is  stamped  by  the  DSF 
and  returned  to  the  OA  Analyst.  Daily  reports,  called 
Maintenance  Data  Reports  (MDRs),  are  sent  to  the 
squadron,  where  they  are  distributed  to  work  centers 
for  verification  against  copy  5  of  the  VIDS/MAF.  Any 
corrections  to  the  MDR  are  annotated  and  the  MDR  Is 
returned  to  the  DSF  to  be  keypunched  once  again. 

12.  Filed 

Copy  1,  once  fully  completed  and  keypunched,  is 
then  kept  in  a  historical  file  within  the  squadron  in 
accordance  with  the  NAMP,  usually  for  a  period  of  six 
months. 

C.  POTENTIAL  BENEFITS  OF  AN  ON-LINE  VIDS/MAF 

Upon  study  of  the  flow  of  the  VIDS/MAF  within  the 
OMA,  several  potential  advantages  of  an  on-line  system 
become  apparent.  Some  of  those  advantages  are: 

1 .  Reduction  of  Lost  Paperwork 

It  was  noted  by  the  VIDS  board  clerk  in  the 
squadron  that  sometimes  copies  of  a  MAF  were  lost, 
leading  to  either  an  extensive  search  for  the  paperwork 
or  the  tedious  reconstruction  of  that  copy.  While  data 
can  certainly  be  lost  in  a  computerized  system,  there 


are  advantages  to  the  elimination  of  a  five  part 
document  and  the  multiple  distribution  of  those  copies. 

2.  Elimination  of  the  Physical  Delivery  of 

VIDS/MAF  Copies 

Delivery  of  paperwork  throughout  the  department 
means  that  someone  has  to  take  time  to  walk  Into 
Maintenance  Control,  receive  the  MAF,  and  then  return 
to  his  work  center.  While  no  time  studies  were 
conducted  In  this  regard,  there  may  be  substantial 
savings  to  be  had  In  this  area. 

3.  Reduction  of  Entry  Errors 

Maintenance  personnel  reported  that  whenever  an 
error  was  caught  on  a  VIDS/MAF,  time  would  often  be 
required  to  track  down  the  Individual  making  the  error 
In  order  to  clarify  his  Intended  entry.  Numerous 
fields  on  the  MAF  contain  only  a  fixed  number  of 
possible  valid  entries.  For  example,  a  squadron  Is 
only  assigned  X  number  of  aircraft  at  any  one  time. 
Therefore,  there  are  only  X  number  of  valid  entries  for 
Bureau  Number  and  Modex.  An  on-line  system  containing 
a  module  (specific  to  the  type  of  aircraft  operated  by 
the  squadron)  might  alert  the  user  that  he  had  made  an 
error,  allowing  him  to  correct  his  entry  on  the  spot. 

4 .  Automatic  Verification  of  Data 

As  Illustrated  In  the  previous  section  on 
VIDS/MAF  flow,  there  are  many  people  actively  Involved 
in  validating  data.  The  master  VIDS  board,  work  center 
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VIDS  board,  and  the  ADB  must  all  contain  the  same  data 
and,  therefore,  must  be  validated  on  a  regular  basis. 
Furthermore,  the  Logs  and  Records  clerk  and  QA  Analyst 
spend  much  of  their  time  validating  the  VIDS/MAF  for 
accuracy  and  completeness.  A  computer  system  capable 
of  verifying  these  Items  would  save  many  man-hours  over 
a  period  of  time. 

5 .  Reduction  In  the  Handling  of  Data 

Outside  the  squadron,  the  Data  Services 
Facility  devotes  much  time  to  the  double  entry  and 
correction  of  VIDS/MAF  data,  and  the  creation  of 
reports  which  are  provided  to  the  squadron.  If  such 
corrections  and  reports  were  done  at  the  squadron  level 
(primarily  on  the  computer),  then  the  processing  of  the 
data  could  take  place  exclusively  at  the  OMA. 


6.  Elimination  or  Reduction  of  a  Number  of 


A  computerized,  on-line  VIDS/MAF  could  signifi¬ 
cantly  reduce  delays  in  reporting.  If  the  Input  of 


data  could  take  place  exclusively  at  the  OMA,  then  the 
time  required  to  keypunch  and  verify  data  at  the  Data 
Services  Facility  would  be  eliminated.  Also,  reports 
could  be  made  available  to  local  managers  more  quickly 
by  computer  than  by  manual  methods,  as  Is  currently 


.  Possible  Reduction  of  Requirements  for  Space  In 
Which  to  Store  Paper  Forms 

The  storage  of  paper  forms  (blank  and  com¬ 
pleted)  takes  up  great  amounts  of  space  In  the  OMA.  By 
storing  forms  and  Information  on  magnetic  media ,  great 
savings  In  space  Is  possible.  These  savings  could 
prove  particularly  beneficial  to  aviation  units  when 
deployed  aboard  ship. 


VII.  LOCAL  AND  NON-NAMP  PROCEDURES 


Voolsey  [Ref.  26:pp.  55-59]  provides  an  enlighten¬ 
ing  account  of  one  often  overlooked,  yet  Important, 
factor  in  determining  system  success— user  (bottom- 
level  management)  acceptance.  He  states  that  even 
though  there  is  a  long-held  view  that  top  management 
commitment  is  the  key  requirement  for  system  accep¬ 
tance,  bottom-level  acceptance  is  equally  as  Important. 

Voolsey  tells  the  story  of  a  "systems  czar"  who  was 
called  into: 

a  large  mldwestern  manufacturing  company  to  design, 
build,  and  gain  acceptance  for  a  wall-to-wall 
production  control  and  reporting  system  for  the  whole 
plant.  He  was  given  virtual  carte  blanche  to  do  it 
any  way  he  wanted,  a  munificent  salary,  all  the 
subordinates  he  needed,  a  budget,  expected  results, 
emd  a  deadline.  [Ref.  26:p.  55] 

As  a  first  step  Voolsey* s  "czar"  sought  to  find  out 

exactly  why  other  large  systems  of  similar  type  had 

failed.  What  he  found  was  that: 

whatever  the  level  of  acceptance  by  top  management, 
the  nonacceptance  by  the  troops  that  had  to  deal  with 
the  system  on  a  day-to-day  basis  was  the  key.  More 
study  showed  that  invariably  the  CRT  displays  and  the 
listing  to  be  used  by  the  grunts  down  below  were 
presented  to  them  as  a  big  surprise  with  the  (usually 
implied)  understanding  that  they  should  take  it 
because  "mother  knows  best".... 

Finishing  his  homework,  he  discovered  what  appeared 
to  be  a  common  thread  among  the  failed  systems.  In 
every  case  where  failure  resulted,  when  the  customary 
exercise  of  "soliciting  lower  management  commitment" 
was  finished,  only  the  sharpest  or  most  open-to- 


change  management  was  tapped.  The  reasons  are 
obvious:  (a)  who  wants  to  listen  to  dummies,  and  (b) 
It’s  always  easier  working  with  people  who  are  ready 
for  change.  [Sef.  26 :p.  55] 

The  systems  analyst  then  went  about  gathering  two 
supervisors  who  had  gone  on  record  as  being  opposed  to 
any  new  system  and  "were  not  exactly  mental  giants." 
After  some  Initial  complaining  by  the  two  supervisors, 
they  then  proceeded  to  tell  the  analyst  that  "for  over 
twenty  years  they  had  been  coming  to  work  an  hour  early 
and  sitting  down  over  coffee  and  scheduling  their  two 
machine  groups  to  try  to  minimize  both  setups  and 
hassle  to  themselves."  After  finding  out  what  the 
supervisors  needed  to  reduce  this  hassle,  the  analyst, 
after  three  tries  and  much  thought,  "presented  them 
with  a  computer-generated  form  in  precisely  the  format 
that  they  could  mark  up  In  the  most  effective  way  for 
their  scheduling." 

By  modifying  the  existing  reporting  system  to 
generate  this  form,  making  a  couple  of  subsequent 
changes  to  the  format  as  requested  by  the  men,  and 
delivering  the  form  to  the  two  supervisors  dally  and  in 
a  timely  fashion,  the  analyst  found  that  production 
under  the  men  began  to  soar.  The  supervisors,  who  had 
previously  resisted  any  new  systems,  seemed  now  to 
become  disgruntled  only  If  their  report  was  not  on 
time.  Woolsey  concludes  that  this  Is  how  systems 
acceptance  should  be. 


Woolsey’s  argument  can  be  aptly  applied  to  the 
NALCOMIS/OMA  concept  as  veil.  A  visit  to  an  OMA 
revealed  that  managers  at  all  levels  within  the 
organization  used  reports  as  tools  In  accomplishing 
their  work.  While  higher-level  managers  like  the 
Commanding  Officer  and  department  heads  tended  to  use 
summary  reports,  such  as  AV-3M  reports,  lower-level 
managers  tended  to  use  more  customized,  local  reports. 

The  purpose  of  this  chapter  Is  to  show  that,  no 
matter  how  streamlined  the  initial  version  of 
NALCOMIS/OMA  may  be,  it  should  provide  managers  with 
the  ability  to  sort  and  format  data  In  a  way  that  Is 
useful  to  them  (as  Individual  decision  makers). 
Furthermore,  managers  should  be  able  to  easily  change 
the  format  of  such  reports  and  have  them  available  on 
an  as  needed  basis  (for  example,  dally  or  at  the  start 
of  each  shift). 

A.  MANAGEMENT  TOOLS 

In  order  to  understand  the  need  for  such  a  capabil¬ 
ity,  It  1 8  Important  to  discuss  some  of  the  tools  used 
by  managers  at  various  levels.  The  following  discus¬ 
sion,  although  the  result  of  study  done  at  one  OMA, 
serves  to  Illustrate  the  Importance  of  local  reports 
and  their  contribution  to  proper  management  of  re¬ 
sources  . 
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.  The  Maintenance  Control  Shift  "Passdown  Log" 
Used  primarily  by  the  Maintenance  Chief  Petty 
Officer  (MCPO),  the  purpose  of  the  Maintenance  Control 
Passdown  Log  (Figures  5a  and  5b)  is  threefold: 

1 )  Serves  as  a  reminder  of  Important  information  to 
be  passed  to  the  next  shift’s  MCPO. 

2)  Aids  the  MCPO  in  coordinating  work  centers  and 
maintenance  control . 

3)  Used  as  a  general  management  tool  (as  described 
below) . 

The  Maintenance  Master  Chief  Petty  Officer  at 
the  OMA  visited  reported  that,  although  not  used  by  all 
OMAs,  the  passdown  log  is  used  by  a  majority  of  O-level 
activities.  By  marking  in  the  log  as  progress  is  made 
on  various  Jobs,  the  log  is  used  as  a  minute-by-minute 
management  tool  during  the  shift.  While  it  contains 
much  of  the  same  information  contained  on  the  VIDS 
board,  the  MCPO  can  obtain,  at  one  glance,  an  overall 
view  of  the  maintenance  effort  in  order  to  prioritize 
his  work. 

Set  up  by  aircraft  side  number  (modex),  the 
status  of  each  aircraft  (indicated  by  UP/DOWN  arrow)  is 
denoted,  along  with  the  discrepancies  outstanding 
against  those  aircraft.  By  using  colored  pens,  the 
MCPO  can  highlight  each  discrepancy  which  keeps  the 
aircraft  in  a  Not  Mission  Capable/Partial  Mission 
Capable  status. 


4Z52 

toc-u* 

2A-0C.T  1 4*  • 

CM  FAoLC 


AlOfc  THtU 


3o2.  ;  >F  fess<ftufe  .  kenP>/ TOtJi&HT  .  saaj»^  j 

_ HAve.fc£j»SV  FOE-  tvj  l/\QgAJtUg»  , 


*304  ;  F^eu  Fucuo  M£55e6  UP1  ^os/MnI 


v  "SCAT  ‘WS^UjCfc  /  «AJV™LL.  CA/J0 


APT  C  O-L.  . 


_3  |  S  •  4 p  S>*Y  TOW|a>KT  ^TOMOft^oco 


Maintenance  Control  Passdown  Log  (left  side) 

Figure  5a 
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Maintenance  Control  Passdown  Log  (right  side) 

Figure  5b 


In  prioritizing  specific  jobs,  the  MCPO  looks 
for  those  discrepancies  which  are  keeping  an  aircraft 
in  a  down  (not  mission  capable)  status  and  checks  the 
VIDS  board  to  see  which  Jobs  are  currently  in  work. 
After  all  downing  discrepancies  are  worked  off,  then 
the  MCPO  might  prioritize  Jobs  by  determining  either 
which  remaining  discrepancy  is  the  most  difficult  to 
work  off  or  which  aircraft  has  the  most  discrepancies 
remaining  against  it. 

The  MCPO  finds  it  difficult  to  provide  a  simple 
recurring  algorithm  to  explain  exactly  how  he  makes  his 
decisions.  He  also  freely  admits  that  other  MCPOs, 
given  the  same  information,  might  make  slightly 
different  decisions  about  how  best  to  employ  his 
resources.  The  MCPO,  then,  must  be  able  to  select  that 
data  which  he  feels  will  help  him  make  the  best 
decisions — thus,  a  customized  tool  such  as  the  passdown 
log  described  here. 

The  log  1 8  also  used  to  make  the  transition 
between  workshlfts  one  which  is  complete  and  smooth. 

If  the  maintenance  department,  while  ashore,  is  working 
only  two  shifts,  then  the  outgoing  nlghtshlft  MCPO  can 
also  make  any  written  comments  Intended  as  reminders 
for  the  incoming  morning  shift  MCPO — for  example,  any 
extraordinary  configuration  changes  or  progress  from 
that  night. 
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Perhaps  most  advantageous  to  the  MCPO  is  the 
use  of  the  log  book  as  a  customized  VIDS  which  contains 
only  that  information  which  the  MCPO  feels  necessary  to 
make  his  decisions.  The  MCPO  also  uses  the  log  to 
conduct  the  maintenance  meeting  with  work  center 
supervisors  at  the  beginning  of  his  shift — again 
proving  the  value  of  such  a  tool  to  the  MCPO. 

Finally,  it  should  be  noted  that  other  managers 
also  find  such  a  management  tool  useful.  The  Mainte¬ 
nance  Officer,  MMCO,  and  others  can  also  be  observed 
occasionally  walking  over  to  the  passdown  log  to  gain 
an  overall  picture  of  the  current  maintenance  effort. 

2 .  The  Dally  Grind 

The  Dally  Grind  (Figure  6),  also  broken  out  by 
aircraft  side  number  (modex),  is  used  by  managers 
throughout  the  organization  -  the  Commanding  Officer, 
Maintenance  Officer,  Maintenance/Material  Control 
Officer,  MCPO,  etc.  Containing  various  statistics 
relevant  to  each  aircraft,  it  is  used  to  gain  an 
overall  feel  for  high-time  components,  phase  inspec¬ 
tions,  engine  times,  oil  samples,  etc. 

The  grind  has  been  developed  in  many  squadrons 
through  the  use  of  a  spreadsheet  program  on  a  microcom¬ 
puter.  The  MCPO,  when  using  the  grind  to  make  his 
decisions  about  which  aircraft  to  schedule  for 
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The  Dally  Grind 
Figure  6 


112 


maintenance,  does  so  with  a  great  deal  of  caution. 
Although  a  quite  useful  tool,  the  grind  is  subject  to 
human  error  and  must  be  verified  regularly  to  ensure 
that  the  data  it  contains  is  correct.  If,  for  in¬ 
stance,  the  grind  Incorrectly  shows  the  number  of 
carrier  arrested  landings  remaining  on  a  particular 
aircraft,  then  the  maximum  allowable  landings  on  the 
aircraft's  hook  point  might  be  exceeded. 

Once  again,  the  grind  does  not  present  any 
information  that  cannot  be  derived  from  the  VIDS  board 
or  other  sources.  It  merely  contains  data  presented 
such  that  It  helps  the  manager  make  better  decisions 
more  quickly.  Additionally,  as  new  managers  come  Into 
the  organization,  the  spreadsheet  format  of  the  dally 
grind  can  be  changed  to  best  meet  their  needs. 

3 .  The  Dally  Status  Report 

While  Functional  Wings  and  Air  Wings  require 
reports  summarizing  aircraft  status  to  be  submitted  on 
a  dally  basis,  the  reports  that  they  require  vary  In 
format  and  actual  content,  depending  on  the  Functional 
or  Air  Wing  Commander’s  desires.  The  Information 
contained  In  these  Wing  reports  are  typically  what  the 
OMA  wants  the  Wing  to  see.  Figures  might  be  somewhat 
manipulated  out  of  fear  of  the  Wing  attempting  to 
micromanage  the  squadron.  In  other  words,  these 
reports  tend  to  be  favorable  rather  than  actual 


snapshots  of  the  activity’s  maintenance  effort.  They 
are,  then,  not  very  valuable  to  squadron  maintenance 
managers . 


Almost  without  exception,  however,  squadrons 
produce,  in  addition  to  a  Wing  status  report,  a 
separate  daily  status  report  (Figure  7).  The  squad¬ 
ron’s  dally  status  report  contains,  not  what  the  OMA 
wants  the  Wing  to  see,  but  information  which  accurately 
represents  the  true  maintenance  situation  in  a  format 
useful  to  them.  Just  as  the  Functional  Wing  Commanders 
request  status  information  in  a  form  that  is  most 
useful  to  them,  squadron  Commanding  Officers  and 
Maintenance  Officers  come  up  with  a  status  report  that 
best  meets  their  information  needs.  Besides  containing 
basic  summary  information  on  aircraft  status,  such  a 
report  might  also  reveal  the  status  of  primary  mission 
subsystems,  thus  becoming  useful  not  only  to  the 
Maintenance  Department  but  also  to  the  Operations 
Department . 

4 .  Quality  Assurance  Trend  Sheet  and  Trend 
Analysis  Report 

When  a  Quality  Assurance  Representative  (QAR) 
receives  copy  2  of  a  VIDS/MAF,  he  places  it  in  a  trend 
book.  Then,  after  corrective  action  has  been  taken  on 
the  discrepancy  and  he  receives  copy  4,  he  enters  data 
from  the  MAF  on  a  trend  sheet  (see  Figure  8).  In  this 
manner  he  keeps  a  record  of  those  discrepancies 
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occurring  which  apply  to  his  particular  area  of 
expertise . 

Once  data  collection  for  a  specific  period  of 
time  (e.g.,  a  month)  Is  complete,  the  QAR  can  then  go 
through  his  trend  hook  and  construct  a  trend  analysis 
report  (see  Figure  9)  in  the  format  preferred  by  the 
squadron.  Interested  primarily  in  recurring  discrepan¬ 
cies,  he  may  construct  such  a  report  by  aircraft, 
subsystem,  or  even  by  pilot. 

Although  Maintenance  Data  Reports  (MDRs) 
received  from  the  Data  Services  Facility  provide 
valuable  QA  Information,  OARs  find  It  useful  to 
construct  their  own  custom  trend/analysis  reports.  In 
addition,  some  Items  of  Interest  to  the  QAR  are  not 
found  on  the  MDR  (for  example,  unnumbered  blocks  on  the 
VIDS/MAF ) . 

5 .  The  Monthly  Maintenance  Flan 

Required  by  the  NAMP,  the  Monthly  Maintenance 
Plan  (MMP )  provides  scheduled  control  of  the  predict¬ 
able  maintenance  workload  for  the  squadron  (Ref.  7:p. 
6-12).  Although  distributed  outside  the  command,  It  is 
used  primarily  by  managers  within  the  command  from  the 
work  center  supervisor  up  to  the  Commanding  Officer. 

In  addition  to  the  minimum  amount  of  information 
required  by  the  NAMP,  Maintenance  Officers  often  add 


information  to  it  that  they  feel  will  help  in  their 
planning  for  the  short  to  medium  range. 
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Trend  Analysis  Report 
Figure  9 


6 .  The  3-M  Supplement 

The  monthly  3-M  report,  which  is  a  summary  of 
Maintenance  Data  Reports  (MDRs),  is  supplemented  by 
this  report.  Also  required  by  the  NAMP,  the  mainte¬ 
nance  analyst  assembles  the  3-M  Supplement  from  MDR 
data  to  give  the  MMCO  and  work  center  supervisors  a 
view  of  man-hour  accounting  within  the  organization. 
The  3-M  Supplement  can  also  reveal  whether  or  not  work 
center  supervisors  are  correctly  documenting  man-hours 
within  their  work  centers. 


In  the  OMA  visited  during  research  for  this 
thesis,  the  Analyst  was  found  to  be  using  a  microcom¬ 
puter  software  package  (LOTUS  123)  to  produce  graphs 
Included  In  the  Supplement  showing  how  the  squadron 
compared  with  other  Pacific  fleet  squadrons  in  the 
areas  of: 

1)  Mission  Capability 

2)  Cannibalizations/100  Flight  Hours 

3)  No.  Defects/100  Flight  Hours 

4)  Aircraft  Utilization 

5)  Corrosion  Control /Treatment 

6)  Equipment  In  Service  Hours 

Although  this  discussion  has  been  limited  to 
Just  a  few  examples  of  reports  being  used  for  manage¬ 
ment  within  the  squadron,  there  were  other  customized 
reports  being  used  by  this  command.  According  to  the 
Maintenance  Master  Chief  Petty  Officer  of  the  squadron 
visited,  other  squadrons  also  use  such  customized  aids. 
These  and  other  tools,  while  extracted  from  data  that 
already  exists  In  some  other  form  In  the  squadron,  are 
assembled  by  time-consuming  manual  methods  with 
occasional  help  from  microcomputer  programs.  By 
allowing  the  manager  to  manipulate  data  and  format 
reports  according  to  local  needs,  NALCOMIS  can  save 
those  Involved  with  such  reports  much  time  and  effort-- 
time  and  effort  which  equates  to  greater  productivity. 


B.  THE  INTERCOM  SYSTEM 

Senn  [Ref.  27 :p.  16]  points  out  the  importance  of 
recognizing  Informal  channels  and  critical  communica¬ 
tion  links  within  an  organization  when  designing 
Information  systems.  One  very  Important  element  that 
exists  at  the  O-level  maintenance  activity  is  the 
Intercom  system. 

The  MMCO  In  the  squadron  visited  during  research 
stated  that  every  OMA  uses  an  Intercom  system.  Tae 
master  unit  Is  located  In  maintenance  control  with  a 
slave  unit  In  each  work  center.  There  Is  also  an 
additional  slave  unit  located  In  the  squadron's 
operations  duty  office  (see  Figure  10).  In  this 
particular  OMA,  the  master  unit  Is  capable  of  communi¬ 
cating  with  any  slave  unit,  but  each  slave  unit  may 
only  communicate  with  the  master  unit  in  maintenance 
control . 

The  type  of  communication  taking  place  between  the 
Operations  Department  (the  duty  officer)  and  mainte¬ 
nance  control  varies  somewhat  between  ship  and  shore 
operations.  This  difference  Is  mainly  due  to  the  fact 
that,  while  shore  based,  the  duty  officer  is  usually  In 
communication  with  the  pilot.  When  aboard  ship,  there 
Is  usually  no  radio  link  between  the  duty  officer  and 
the  pilot.  Therefore,  certain  Information,  such  as 
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status  of  the  aircraft,  cannot  always  be  passed  from 
the  duty  officer  to  maintenance  control. 

Information  which  gets  passed  back  and  forth  from 
maintenance  control  to  the  work  centers,  however,  does 
not  change  significantly  when  changing  from  ship  to 
shore  operations.  While  no  study  was  conducted  with 
regard  to  the  volume  and  type  of  exchanges  between 
maintenance  control  and  work  centers,  the  MMCO  indi¬ 
cated  that  the  Intercom  system  was  "an  extremely 
valuable  tool  which  is  used  constantly.  We  couldn’t 
get  along  without  it." 

The  maintenance  chief  petty  officer  (MCPO)  and 
those  assisting  him  within  maintenance  control  use  the 
Intercom  to  gain  information  necessary  to  make  minute- 
by-minute  decisions.  A  quick  call  to  a  work  center  can 
provide  the  real  time  status  of  a  particular  Job. 
Another  call  to  the  work  center  supervisor  can  reveal 
to  the  MCPO  which  individuals  are  available  (and 
qualified)  to  perform  a  specific  task.  The  MCPO  can 
often  quickly  locate  an  individual  or  piece  of  equip¬ 


ment  by  calling  all  work  centers  at  once. 

While  the  Intercom  may  not  be  considered  when 
referring  to  NALCOMIS/OMA,  it  will  continue  to  play  a 
role  in  squadron  decision  making.  The  Intercom  will 
become,  although  not  in  a  formal  sense,  a  part  of 
NALCOMIS/OMA.  As  will  be  shown  in  the  next  chapter. 
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this  communication  tool  between  maintenance  control  and 
work  centers  should  be  considered  when  deciding  which 
functions  of  the  OMA  to  automate. 

C.  NALCOMIS/OMA  AND  LOCAL  REPOSTING 

Plans  for  NALCOMIS/OMA  do  not  Include  any  capabili¬ 
ties  for  creating  reports  at  the  squadron  level.  It 
will  be  possible  to  generate  predefined  reports  to  be 
sent  to  the  Type  Commander,  Functional  Wing,  or  even 
the  squadron.  However,  it  will  not  be  possible  for  a 
maintenance  manager  within  the  squadron  to  create  new 
reports . 

There  are  several  reasons  why  providing  local 
managers  with  the  ability  to  create  reports  might 
appear  undesirable  to  those  managing  the  development  of 
NALCOMIS/OMA: 

1)  Providing  such  capabilities  could  Increase 
development  time  and  cost. 

2 )  Someone  would  have  to  maintain  the  software 
modules  which  are  responsible  for  formatting  and 
producing  the  reports  [Ref.  11], 

3)  Data  base  integrity  could  be  Jeopardized.  If  a 
user  became  too  knowledgeable  in  learning  how  to 
manipulate  data,  he  might  alter  the  data  base  in  an 
undesirable  manner  [Ref.  10]. 

While  there  is  no  doubt  that  providing  the  capabil¬ 
ity  to  produce  local  management  reports  would  take 
extra  development  effort,  it  is  necessary  to  consider 
the  benefits  of  such  capabilities  to  the  OMA. 


A  brief  illustration  of  the  importance  of  user 
acceptance  to  system  success  was  provided  at  the 
beginning  of  this  chapter.  Certainly,  providing 
features  to  NALCOMIS/OMA  (at  a  reasonable  cost)  which 
would  Increase  user  acceptance  would  be  highly  desir¬ 
able.  There  are  several  other  reasons  why  automating 
local  reports  would  be  beneficial. 

First,  man-hours  are  already  being  expended  on 
collecting  data,  formatting,  and  preparing  local 
reports.  The  squadron  visited  In  preparing  this  thesis 
was  producing  such  reports  both  manually  and  on  a 
personal  computer.  While  a  few  examples  of  such  local 
reports  were  given  earlier  In  this  chapter.  It  must  be 
remembered  that  valuable  man-hours  were  spent  putting 
these  and  other  reports  together.  Management  consid¬ 
ered  these  reports  so  beneficial  that  they  were  willing 
to  assign  personnel  In  Maintenance  Administration  and 
Quality  Assurance  to  enter  data  on  a  squadron  owned 
microcomputer  on  a  dally  basis.  NALCOMIS/OMA  should  be 
designed  to  save  the  man-hours  currently  wasted  on  this 
additional  data  handling. 

Secondly,  by  entering  Information  from,  for 
instance,  a  stack  of  VIDS/MAFS  to  a  microcomputer, 
there  is  a  chance  that  typing  errors  will  occur.  Any 
Incorrect  Information  that  ends  up  on  a  local  report 
has  the  potential  of  causing  an  Incorrect  decision  to 


be  made.  In  addition,  extra  time  would  need  to  be 
spent  In  correcting  the  error.  If  It's  found.  Produc¬ 
tivity  at  every  level  within  the  squadron,  therefore, 
may  be  adversely  affected. 

Providing  the  capability  to  create  custom  reports 
would  also  prove  valuable  to  those  squadrons  which, 
upon  changing  Commanding  Officer  or  Maintenance 
Officer,  find  themselves  producing  new  daily  reports. 
Each  report  that  is  generated  manually  requires  at 
least  one  person  to  retrieve,  produce,  and  distribute 
the  report.  Any  time  savings  in  this  area  can  be 
applied  to  more  meaningful  tasks. 

Providing  software  modules  which  allow  the  genera¬ 
tion  of  local  reports  would  not  have  to  mean  that 
maintenance  of  NALCOMIS/OMA  software  modules  would  be 
unmanageable.  NALCOMIS/OMA  could,  perhaps,  allow  the 
user  to  specify  the  desired  fields  and  format  for  a 
local  report.  By  allowing  the  format  to  be  saved  and 
named,  the  report  could  be  requested  as  needed  by  the 
user--dally,  for  example. 

D.  SUMMARY 

Top-level  management  acceptance  is  not  the  only 
determinant  of  a  system’s  success--bottom-level 
management  acceptance  is  equally  as  important  [Ref. 
26:p.  55].  In  order  to  provide  the  managers  in  the  OMA 
with  the  information  needed  to  effectively  make 
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decisions,  NALCOMIS/OMA  should  allow  Its  users  to 
select  and  format  data  to  be  used  in  local  reports. 

Many  man-hours  are  currently  expended  producing 
customized  reports  for  managers  within  the  squadron. 
These  reports  are  used  to  make  decisions  and  are 
changed  when  necessary  in  order  to  fit  individual  (or 
group)  management  styles.  In  addition,  an  intercommu¬ 
nication  system  between  Maintenance  Control  and  each 
work  center  aids  the  MCPO  in  making  his  decisions. 

While  NALCOMIS/OMA  is  planned  to  provide  some  pre¬ 
determined  local  reporting  capabilities,  the  squadron 
is  likely  to  continue  producing  the  other  local  reports 
and  management  tools  mentioned  unless  the  design  of 
NALCOMIS/OMA  incorporates  such  capabilities.  By 
allowing  squadron  users  to  define  and  produce  custom 
reports,  they  would  be  better  able  to  effectively 
manage  their  resources. 


VIII.  ESTABLISHING  AN  EFFECTIVE  INFORMATION  SYSTEM  FOR 
THE  OMA 

Chapter  IV  presented  five  attributes  required  for 
an  effective  information  system  [Ref.  16:p.  5]: 

1)  Decision-oriented  reporting. 

2)  Effective  processing  of  data. 

3)  Effective  management  of  data. 

4)  Adequate  flexibility. 

5)  A  satisfying  user  environment. 

Next,  some  of  the  problems  that  users  have  experi¬ 
enced  (and  expect  to  experience)  with  the  NALCOMIS 
Phase  II  system  were  identified.  The  NAMP  procedures 
currently  used  in  the  collection  of  most  of  the  data  at 
the  OMA  were  discussed  and  some  of  the  potential 
benefits  that  a  computerized,  on-line  system  has  to 
offer  were  identified.  Then,  the  importance  of  local 
procedures  and  reporting  to  bottom-level  user 
acceptance  of  NALCOMIS/ OMA  was  discussed. 

Now  it  will  be  shown  how  these  problems  and 
procedures  relate  to  each  of  the  five  attributes 
mentioned  above.  By  doing  so,  the  importance  of 
providing  the  OMA  with  local,  pertinent,  and  flexible 
reporting  capabilities  will  be  established.  Each 
attribute  will  be  discussed  in  general  and  the  research 
findings  applied.  In  the  final  chapter,  additional 
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recommendations  for  providing  managers  with  useful  low- 
level  reporting  capabilities  will  be  made. 

As  stated  earlier,  NALCOMIS  should  "make  a  major 
Impact  on  a  key  area  associated  with  the  success  of  the 
business."  [Ref.  16:p.  98]  Since  the  OMA  is  in 
business  to  provide  mission  capable  aircraft,  NALCOMIS 
should  provide  its  greatest  benefits  in  this  area. 
Therefore,  it  will  be  shown  how  the  objectives  of 
NALCOMIS/OMA  can  be  effective  and,  in  so  doing,  provide 
maximum  benefits  to  the  OMA. 

A.  DECISION-ORIENTED  REPORTING 

Decision-oriented  reporting  means  that  "output  from 

the  system  is  designed  to  facilitate  decision  making  by 

those  persons  who  receive  the  output."  [Ref.  16 :p.  5] 

NALCOMIS/OMA  should  provide  the  maintenance  manager 

with  reports  which  are  well-suited  to  aid  in  his 

decision  making  processes.  These  reports  should  be 

flexible  enough  to  meet  the  changing  needs  of  the  OMA 

and  the  maintenance  manager.  They  should  also  provide 

the  correct  amount  of  information  necessary  to  quickly 

and  effectively  make  specific  decisions. 

1 .  Tailoring  Information  to  the  Decision  Maker 

Nichols  [Ref.  28:p.  73]  states  that 

The  information  that  is  generated  and  made  available 
within  the  organization  should  be  tailored  to  the 
task  at  hand. . .The  emphasis  is  upon  supplying  each 
decision  point  with  enough  information,  of  the  right 
quality,  when  it  is  needed. 


But  Nichols  warns  that  the  Information  necessary  for 
decision  making  does  not  remain  constant.  He  says  that 
the  Information  supplied  at  the  decision  point  Ideally 
should  be  changed  "when  changes  [occur]  in  the 
capabilities  of  the  decision-maker,  or  In  the 
Information  made  available  or  pertinent  to  the 
decision,  or  If  the  manager  responsible  for  a  given 
decision  [is]  changed." 

The  previous  chapter  Identified  some  of  the 
ways  In  which  one  OMA  uses  local,  customized  reports  to 
satisfy  the  needs  of  Its  decision  makers.  Although 
several  objections  to  having  NALCOMIS/OMA  provide  such 
customized  reporting  were  listed,  the  Importance  of 
getting  the  right  information  to  the  right  person 
cannot  be  overemphasized.  It  is  Important  to  satisfy 
the  user-manager  In  the  OMA,  but  It  Is  also  necessary 
to  ensure  that  better  decision  making  takes  place. 

If  NALCOMIS/OMA  does  not  provide  the  mainte¬ 
nance  manager  with  the  Information  that  he  needs,  he 
will  obtain  that,  or  substitute  Information  from  some 
other  source.  If  NALCOMIS/OMA  doesn't  provide  the  type 
of  local  reports  currently  prepared  by  naval  aviation 
squadrons,  then  the  squadrons  will  continue  to  prepare 
them  manually  or  continue  using  other,  locally  devel¬ 
oped  computer  systems.  So,  the  importance  of  such 
local  reports  has  been  established.  Although  no  time 


study  was  done  to  estimate  man-hours  spent  preparing 
these  local  reports,  the  amount  Is  clearly  significant. 

2 .  Satisfying  Changing  Needs 

It  is  highly  desirable  (from  the  standpoint  of 
the  OMA)  that  NALCOMIS/OMA  provide  some  custom  report¬ 
ing  capabilities.  In  addition,  the  OMA  should  also  be 
able  to  change  the  content  and  format  of  these  reports 
relatively  easily.  Maintenance  managers  constantly 
transfer  in  and  out  of  the  OMA.  These  same  managers 
also  routinely  and  periodically  change  jobs  within  the 
organization.  When  a  new  manager,  with  a  decision 
making  style  different  from  that  of  his  predecessor, 
takes  over  a  position,  he  often  needs  different 
information  than  that  which  has  previously  been 
provided. 

It  is  also  Important  to  be  able  to  manipulate 
data  in  order  to  "convert  data  into  potential  Informa¬ 
tion  relevant  to  the  present  and  the  future."  [Ref. 
28:p.  74]  Since  NALCOMIS/OMA  (as  currently  planned) 
will  not  allow  maintenance  managers  to  create  custom 
reports  or  allow  users  to  download  and  store  private 
data  bases,  such  manipulation  will  have  to  occur 
external  to  NALCOMIS.  Again,  if  the  user  perceives  a 
need  for  Information  which  NALCOMIS  is  not  providing, 
he  will  obtain  that  information  by  other  means — and  he 
may  question  the  usefulness  of  NALCOMIS. 
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3.  Providing  the  Correct  Amount  of  Information 
"Existing  computer-based  systems  often  provide 

too  much  data;  users  frequently  have  felt  overloaded 
with  Information  that  could  not  possibly  be  analyzed." 
[Ref.  21 :p.  77]  In  order  for  NALCOMIS  output  to  prove 
useful  to  managers,  reports  and  screen  output  must  be 
free  of  information  that  Is  not  pertinent  or  which 
distracts  from  other,  more  relevant  Information. 

4.  An  Example  of  Decision-Oriented  Reportln 


The  Maintenance  Control  Passdown  Log,  discussed 
In  the  previous  chapter,  can  be  used  to  Illustrate  the 
Importance  of  providing  the  right  amount  of 
Information.  The  log  provides  the  MCPO  with  the 
Information  he  needs  to  obtain  an  overall  view  of  the 
current  maintenance  situation.  However,  nearly  all  of 
the  Information  contained  In  the  log  may  be  found  by 
looking  at  the  VIDS  board.  Although  the  MCPO  Is  able 
to  obtain  some  Information  more  quickly  through  verbal 
communication  with  the  work  centers  (l.e.  the  Intercom 
system),  he  depends  mostly  on  Information  contained  on 
the  VIDS  board. 

Why,  then,  does  the  MCPO  feel  that  It  Is 
necessary  to  duplicate  Information  from  the  VIDS  board 
to  the  log?  There  are  several  possible  reasons. 

First,  the  log  can  provide  a  more  recent 
snapshot  of  the  maintenance  situation  than  the  VIDS 
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board  provides.  For  example,  there  is  a  lag  between 
the  time  that  a  MAF  is  completed  in  the  work  center  and 
the  time  that  it  is  received  in  Maintenance  Control. 
But,  because  the  MCPO  is  in  verbal  contact  with  the 
work  center,  he  can  make  an  entry  in  the  log  which 
reflects  the  fact  that  the  job  has  been  completed 
(noting,  of  course,  that  the  job  is  not  actually 
finished  until  all  of  the  paperwork  is  completed). 

Secondly,  and  most  pertinent  to  this  discus¬ 
sion,  the  log  contains  the  amount  of  information  that 
the  MCPO  needs  to  prioritize  jobs  and  make  other  dally 
decisions.  The  VIDS  board,  while  designed  to  provide 
managers  with  a  visual  representation  of  the  overall 
maintenance  situation,  contains  more  information  than 
is  needed  at  times. 

By  extracting  from  the  VIDS  board  a  list  of  the 
discrepancies  which  place  each  of  the  aircraft  in  a 
partial  mission  capable  or  not  mission  capable  status, 
and  writing  that  information  in  the  log,  the  MCPO  can 
eliminate  any  information  that  he  uses  less  frequently 
or  not  at  all  in  his  dally  decision  making.  For 
example,  the  MCPO  can  write  a  short,  plain  English 
description  (typically  one  or  two  key  words)  of  each 
discrepancy.  He  can  then  use  different  colored  ink 
markers  to  distinguish  between  partial  and  not  mission 
capable  discrepancies,  completed  repairs  which  are 


awaiting  paperwork,  etc.  The  MCPO  can  create  a 
management  tool  that  contains  the  Information  that  he 
needs  to  make  most  of  his  decisions.  He  no  longer 
needs  to  walk  to  the  VIDS  board,  lift  up  the  VIDS  board 
pockets,  and  read  the  full  description  of  the  discrep¬ 
ancies  against  an  aircraft  In  order  to  determine  the 
status  of  that  aircraft.  He  can  simply  glance  at  the 
log,  see  the  list  of  color  coded  aircraft  discrepancies 
in  plain  English,  and  quickly  become  familiar  with  the 
current  maintenance  situation  and  any  priorities  that 
have  been  set. 

The  Maintenance  Control  Passdown  Log  Is  also  a 
more  flexible  tool  than  the  VIDS  board.  As  the  MCPO’s 
Information  changes,  the  log  can  be  updated.  If 
aircraft,  equipment,  or  requirements  for  maintenance 
change,  the  log  can  quickly  and  easily  be  changed  as 
well.  (More  will  be  said  concerning  flexibility  later 
In  this  chapter.) 

Finally,  the  log  provides  information  which  Is 
tailored  to  the  needs  of  the  manager.  If  a  new  Chief 
Petty  Officer  takes  over  the  job  of  MCPO,  he  can 
Immediately  tailor  the  log  so  that  it  contains  that 
Information  which  he  needs.  For  example,  a  new  MCPO 
may  need  to  list  the  work  center  codes  alongside  (or 
above)  the  dlscrlptlon  of  the  discrepancies  in  the  log. 
A  more  experienced  MCPO,  on  the  other  hand,  may  know 


which  work  centers  are  responsible  for  Baking  specific 
repairs  and  Bay  not  need  to  record  the  work  center 
lnforaatlon.  The  log.  In  effect,  can  be  changed  to  fit 
the  style  and  lnforaatlon  needs  of  the  Individual 
1  decision  Baker. 


5 .  Other  Concerns 

Other  concerns,  discovered  during  the  inter¬ 
views  with  users  of  the  NALCOMIS  Phase  II  systea,  are 
worth  aentlonlng  here.  Chapter  V  said  that  users  were 
concerned  that:  1)  NALCOMIS/ OMA  alght  be  expected  by 
users  to  do  aore  for  the  OMA  than  It  Is  designed  to  do 
and  2)  NALCOMIS,  In  the  opinion  of  soae  Phase  II  users, 
does  not  provide  such  aanageaent  support. 

By  providing  decision-oriented  reporting, 
NALCOMIS  would  likely  satisfy  (or  partially  satisfy) 
both  concerns.  NALCOMIS/OMA,  by  putting  the  right 
lnforaatlon  In  the  hands  of  the  users,  would  be 
providing  aore  aanageaent  support  than  Is  currently 
planned.  Also,  those  using  the  lnforaatlon  would 
quickly  coae  to  learn  what  NALCOMIS  can  and  cannot  do 
for  then.  If  custoalzed  reports  could  be  generated  by 
NALCOMIS,  aanagers  night  even  benefit  In  ways  that  have 
not  been  anticipated  by  those  developing  the  systea. 

In  effect,  the  very  scope  of  NALCOMIS  could  be 
broadened  by  the  users  theaselves. 
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B.  EFFECTIVE  PBOCESSING  OF  DATA 


The  next  desirable  attribute  of  an  Information 
system,  effective  processing  of  data,  means  that  the 
"checks  and  controls  on  Input  and  output  are 
appropriate,  system  timing  Is  meaningful  In  the  context 
of  the  application,  and  the  utilization  of  the  hardware 
and  software  environment  Is  efficient."  [Kef.  16:p.  5] 
NALCOMIS/OMA  should  allow  for  quick  and  easy  user 
access,  automatically  verify  data  as  It  enters  the 
system,  and  process  data  more  quickly  and  accurately 
than  current  manual  methods.  Further,  NALCOMIS/OMA  may 
collect  or  process  data  Into  Information  In  ways  which 
aren’t  possible  with  manual  methods. 

1 .  User  Access  to  NALCOMIS 

In  order  for  NALCOMIS  to  Improve  decision 
making  and  productivity  at  the  OMA,  the  system  must 
allow  for  quick  and  easy  user  access.  While  on-line 
features  will  supposedly  provide  fast  response  to  user 
needs,  there  are  other  considerations.  As  discussed  In 
Chapter  V,  some  users  of  the  Phase  II  system  were 
concerned  that.  In  a  hectic  operational  setting, 
NALCOMIS  might  prove  to  be  slower  than  the  current 
manual  system. 

One  major  concern  Is  that,  with  only  one 
NALCOMIS  terminal  available  In  each  work  center,  only 
one  user  In  each  work  center  will  be  able  to  access 
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NALCOMIS  at  any  one  time.  The  only  alternative 
available  to  a  user  waiting  to  access  a  work  center 
terminal,  other  than  to  continue  waiting.  Is  to  try  and 
locate  an  available  terminal  In  a  different  work 
center. 

Another  concern  Is  that  some  terminals  may  not 
be  used  as  much  as  others.  Plans  call  for  one  terminal 
per  work  center.  This  somewhat  arbitrary  placement  of 
terminals  could  prove  to  be  suboptlmal.  For  example, 
one  terminal  may  not  be  enough  to  handle  the  amount  of 
use  In  the  avionics  work  center,  while  a  terminal  in 
another  work  center,  like  ordnance,  stands  Idle  a  large 
percentage  of  the  time. 

2.  Sneed  and  Accuracy  of  Processing 

When  NALCOMIS/OMA  Is  Installed  and  running, 
will  It  prove  to  be  faster  and  more  accurate  than 
current  manual  methods?  If  top  management  la  to  expect 
that  NALCOMIS  will  contribute  toward  better  decision 
making  and  higher  productivity  (and,  thus,  improved 
mission  capability),  then  It  must  be  faster  and  more 
accurate  than  the  present  manual  system. 

NALCOMIS,  as  a  computerized  system,  will 
process  Information  much  faster  once  that  Information 
Is  entered  at  work  center  terminals.  But,  in  order  to 


make  a  useful  comparison  of  computerized  and  manual 
systems,  the  time  required  for  processing  data  must  be 


looked  at  In  Its  entirety.  Processing  must  be 
considered  to  start  as  users  begin  to  log  onto  the 
systea  and  It  aust  be  considered  to  end  when  users 
coaplete  their  tasks  (or  receive  output  froa  the 
systea ) . 


Users  Identified  three  potential  probleas  which 
could  negatively  lapact  the  speed,  and  therefore 
usefulness,  of  NALCOMIS/OMA  (see  Chapter  V). 

1 )  Each  user  aust  go  through  slgn-on  procedures  to 
gain  access  to  the  systea.  In  soae  Instances,  the 
paper  VIDS/MAF  systea  currently  In  use  Is  faster  In 
this  respect.  Under  the  present  systea.  the  VIDS/MAF 
aay  be  accessed  by  slaply  retrieving  the  MAF  froa  the 
VIDS  board,  aaklng  a  pen  entry,  and  replacing  the 
MAF. 

2)  If  two  or  aore  users  In  a  work  center  need  access 
to  the  systea  at  the  saae  tlae,  all  but  one  user  aust 
either  wait  or  search  for  an  available  teralnal  In 
another  work  center.  The  VIDS  board,  on  the  other 
hand,  allows  aultlple  users  to  access  different  MAFs 
simultaneously. 

3)  NALCOMIS  aay  not  present  data  In  an  optimal 
Banner.  Users  noted  that  the  maintenance  Chief  Petty 
Officer,  for  exaaple,  aay  need  to  go  through  four  or 
five  different  coaputer  conversations  In  order  to  get 
enough  Information  to  aake  a  slaple  decision.  The 
saae  decision  would  generally  be  Bade  faster  oy 
obtaining  Information  contained  In  a  locally  main¬ 
tained  Maintenance  Control  Paasdown  Log. 


C.  EFFECTIVE  MANAGEMENT  OF  DATA 

NALCOMIS/OMA  should  provide  for  the  effective 
management  of  data.  Attention  should  be  paid  to  "the 
accuracy  of  Input  data,... the  aalntenance  of  integrity 
once  data  are  stored  within  the  system  [and]  the 
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security  requirements  while  the  data  are  being  used  and 
on  disposal."  [Kef  16:p.  5] 

1 .  Automatic  Verification  of  Data 

After  tracing  the  flow  of  the  VIDS/MAF  within 
the  OMA .  several  advantages  of  having  a  computerized, 
on-line  VIDS/MAF  system  were  Identified  (see  Chapter 
VI).  One  of  these  advantages,  automatic  verification 
of  data,  could  potentially  save  many  man-hours  that  are 
currently  spent  manually  verifying  data  for  correct¬ 
ness. 

The  work  center  supervisor.  Logs  and  Records 
clerk,  and  Quality  Assurance  analyst  spend  much  of 
their  time  ensuring  that  Information  entered  on  the 
VIDS/MAF  Is  correct.  In  addition,  maintenance  control 
and  work  center  personnel  must  constantly  ensure  that 
their  VIDS  boards  (and  the  aircraft  discrepancy  book) 
all  contain  the  same  Information. 

It  was  also  noted  that  whenever  a  VIDS/MAF 
error  was  detected,  someone  (l.e.,  the  VIDS  board 
clerk)  would  have  to  take  the  time  to  trace  the  source 
of  the  error  and  make  the  correction.  By  checking 
Information  as  It  Is  entered  at  the  keyboard, 
MALCOMIS/OMA  will  therefore,  reduce  such  occurrences. 

As  Lucas  [Ref.  21:p.  345]  states: 

A  well-designed  system  handles  [Input]  errors;  that 
Is,  It  corrects  them  or  notifies  someone  of  the 
errors  and  continues  producing  valid  output.  It  Is 
not  unusual  to  find  more  than  half  the  Instructions 


In  a  program  devoted  to  error  detection  and  handling, 
especially  In  an  on-line  system. 

Notice  that  Lucas  emphasizes  the  importance  of  handling 

Input  errors  In  on-line  systems  by  shoving  the  large 

portion  of  programming  devoted  to  handling  these 

errors . 

2 .  Security 

In  previous  chapters,  user  Identification  and 
access  to  NALCOMIS/OMA  was  discussed.  The  Phase  II 
users  vere  concerned  chiefly  that,  for  the  sake  of 
convenience,  lists  of  passwords  might  be  freely  passed 
among  NALCOMIS  users. 

If  passwords  are  freely  exchanged  among 
squadron  personnel,  then  there  Is  a  chance  that  users 
will  access  conversations  which  they  are  not  authorized 
to  use.  In  addition,  concern  was  expressed  that,  if 
responsibilities  for  maintenance  actions  needed  to  be 
traced  (l.e.,  after  an  aircraft  mishap),  users  might  be 
able  to  claim  that  their  password,  and  thus  NALCOMIS, 
had  been  compromised. 

If  adequate  security  controls  are  not  built 
Into  NALCOMIS/OMA  from  the  beginning,  attempts  to  add 
controls  later  will  be  very  expensive  and  could  prove 
to  be  unsuccessful  [Ref.  16:p.  94].  Therefore, 
NALCOMIS/OMA  developers  should  be  aware  of  the  problems 


which  have  been  Identified  and  take  action  to  correct 


Many  state-of-the-art  system  access  technolo¬ 
gies  (such  as  devices  which  recognize  voice,  retinal, 
or  fingerprint  patterns)  offer  promising  solutions  to 
security  problems  but  are  not  part  of  the  current  plans 
for  NALCOMIS/OMA.  However,  such  technologies  should  be 
considered  in  long-range  plans  for  changes  or  updates 
to  NALCOMIS/OMA. 

Until  more  sophisticated  technologies  can  be 
feasibly  Incorporated  into  NALCOMIS/OMA,  developers 
should  force  randomly  generated  passwords  upon  the 
users.  Also,  the  NAMP  should  provide  clear  guidance  on 
the  use  of  passwords.  The  establishment  of  password 
lists  should  be  forbidden  by  the  NAMP  and  supported  by 
other  Navy  instructions  and  inspection  procedures 
should  be  established  which  will  ensure  that  squadrons 
are  complying  with  these  regulations. 

D.  ADEQUATE  FLEXIBILITY 

A  system  which  contains  adequate  flexibility  should 
be  able  to  "adapt  to  changes  in  the  behavioural 
characteristics  of  those  persons  associated  with  it." 
[Ref.  16:p.  5]  The  steady  turnover  in  squadron 
personnel  means  that  decision  making  techniques  and 
other  personal  management  characteristics  within  the 
OMA  will  be  constantly  changing  with  time. 

Flexibility,  as  we  have  already  pointed  out,  is 
Important  in  achieving  user  satisfaction  with  an 


information  system.  Designing  flexibility  into  a 
system  can  also  prolong  its  useful  life,  thus  reducing 
the  long-run  cost  of  the  system  [Ref.  16 :p.  92].  So,  a 
flexible  system  is  not  only  preferred  by  the  user,  it 
is  also  beneficial  to  the  organization  as  a  whole. 

As  managers  learn  to  use  NALCOMIS,  they  will  likely 
discover  ways  in  which  the  system  can  help  them  improve 
their  decision  maklng--ways  which  may  not  have  been 
perceived  by  system  designers.  NALCOMIS  should  provide 
flexible  services  so  that  managers  may  take  advantage 
of  such  opportunities. 

E.  SATISFYING  USER  ENVIRONMENT 

A  system  Is  said  to  provide  a  satisfying  user 
environment  if  the  "machine-people  interfaces  are 
appropriate  for  the  tasks  involved."  [Ref.  16 :p.  5] 
Users  must  find  the  system  easy  to  use  and  it  must  be 
perceived  by  them  as  providing  useful  information  and 
services . 

The  Interface  between  NALCOMIS  and  users  must  be 
simple  and  easy  to  use  from  the  user's  standpoint. 

These  NALCOMIS  interfaces  generally  take  the  form  of 
either  terminal  procedures,  screens,  or  reports.  The 
term  interface,  then,  describes  that  part  of  the  system 
which  the  user  sees. 

The  user  is  important  in  determining  how  effective 
(and  ultimately,  how  successful)  NALCOMIS/OMA  will  be. 


This  is  particularly  true  since  NALCOMIS  is  an  on-line 
system.  As  Brookes  [Ref.  16:p.  269]  says: 


Behavioural  factors  relating  to  operator  satisfaction 
with  the  Interface  design  and  overall  system  logic 
are  more  important  in  an  on-line  system  than  in  a 
batch  system  due  to  the  close  interaction  and  direct 
penetration  of  the  on-line  system  into  the  workplace. 

User  satisfaction  will  depend  on  how  well  NALCOMIS 
can  meet  the  informational  needs  of  decision  makers— 
decision  makers  who  solve  problems  in  different  ways. 
NALCOMIS  must  also  present  this  information  in  a  format 
which  appears  logical  to  the  user.  Therefore,  NALCOMIS 
developers  must  conduct  further  research  at  the  OMA  to 
determine  how  NALCOMIS /OMA  can  present  the  information 
in  such  a  way  that  it  suits  the  decision  maker.  Local 
and  informal  procedures  in  use  under  the  current  manual 
system,  such  as  those  discussed  in  this  thesis,  must  be 
considered  when  development  of  NALCOMIS/OMA  continues. 

As  revealed  in  Chapter  V,  some  Phase  II  users  felt 
that  NALCOMIS  was,  in  some  regards,  difficult  to  use. 
Some  users  found  that  learning  to  use  the  system  was 
difficult.  Also,  some  expressed  dissatisfaction  with 
having  to  go  through  numerous  menu  screens  in  order  to 
accomplish  certain  tasks.  Paper  printouts  were  being 
used  by  some  because  they  are  faster  and  easier  to  use 
than  the  NALCOMIS  screens. 

Many  lessons  on  ease  of  use  can  be  learned  from  the 
Phase  II  system.  Phase  II  system  problems  in  this  and 
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other  areas  should  be  thoroughly  documented  and,  when 
development  of  Phase  III  is  resumed,  solutions  to  these 
problems  should  be  included  in  NALCOMIS/OMA.  Recommen¬ 
dations  for  screen  and  conversation  redesign,  for 
example,  should  be  a  top  priority  for  NALCOMIS  develop¬ 
ers  so  that  users  will  be  able  to  process  information 
in  a  shorter  average  time  than  is  required  to  process 
the  current  paper  MAF. 

The  fact  that  the  current  paper  system  (i.e., 
VIDS/MAF)  might  prove  to  be  faster  than  NALCOMIS  caused 
some  concern  in  Phase  II  users  who  were  interviewed  for 
this  thesis.  For  the  OMA  user,  a  faster  system  might 
be  perceived  as  a  system  which  is  easier  to  use.  This 
perception  could  lead  to  a  reduction  in  the  level  of 
user  satisfaction.  If  users  become  dissatisfied  with 
the  performance  of  NALCOMIS,  they  could  choose,  in 


certain  Instances,  to  Ignore  the  system. 

Those  involved  with  developing  NALCOMIS/OMA  should 
reexamine  the  currently  planned  hardware  topology  for 
NALCOMIS/OMA.  Time  studies  should  be  conducted  at  the 
OMA  to  determine  the  frequency  with  which  workers 
require  access  to  VIDS  information  in  each  work  center. 
These  studies  are  necessary  to  determine  whether  one 
NALCOMIS  terminal  per  work  center  will  be  enough  to 
handle  the  number  of  workers  requiring  access  to 
NALCOMIS/OMA  during  peak  work  loads. 


F.  SUMMARY 


There  are  five  attributes  of  an  effective 
information  system  [Ref.  16:p.  5]: 

1)  Decision-oriented  reporting. 

2)  Effective  processing  of  data. 

3)  Effective  management  of  data. 

4)  Adequate  flexibility. 

5)  A  satisfying  user  environment. 

In  this  chapter,  the  research  findings  discussed  in 
previous  chapters  were  applied  to  these  attributes  in 
order  to  show  the  Importance  of  providing  better  local 
reporting  capabilities  in  NALCOMIS/OMA. 

NALCOMIS,  in  order  to  significantly  improve  mission 
capability,  must  provide  the  information  necessary  to 
Improve  managerial  decision  making  and  allow  users  to 
quickly  and  easily  use  the  system.  Managers  must 
receive  the  information  they  need,  when  they  need  it, 
in  order  to  make  decisions  quickly  and  effectively. 
Workers  must  find  NALCOMIS  easy  to  access  and  use,  so 
that  they  will  be  able  to  spend  time  working  on 
aircraft  and  not  performing  administrative  tasks. 


IX.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

1 .  Improving  Mission  Capability 

The  Organizational  Maintenance  Activity  Is  In 
business  to  provide  mission  capable  aircraft.  If  It  is 
to  help  significantly  improve  mission  capability  at  the 
OMA ,  NALCOMIS/OMA  must  provide  improvements  In  two  key 
areas:  decision  making  and  worker  productivity, 

a.  Decision  Making 

NALCOMIS/OMA,  as  currently  planned,  will 
support  decision  making  at  the  OMA  through  the  use  of 
predefined  reports  and  on-line  screens.  The  reports 
that  will  be  generated  by  NALCOMIS  are  primarily 
summarized  reports  to  be  sent  to  higher  levels  of 
management.  As  one  moves  down  the  management  chain  of 
command  in  the  OMA,  however,  the  need  for  information 
generally  changes  to  that  which  Is  more  detailed  and 
real-time  In  nature.  As  more  and  more  detail  Is 
required  by  these  managers.  It  will  become  more  likely 
that  pre-defined  reports  will  not  satisfy  their 
Information  needs. 

Providing  maintenance  managers  with  the 
capability  of  creating  local,  customized  reports  would 
require  that  the  developers  change  their  present  plan 


for  NALCOMIS/OMA.  The  ability  to  create  custom  reports 
would  ensure  that  local  squadron  decision  makers 
receive  the  Information  they  need,  when  they  need  It — 
thus  helping  to  Improve  mission  capability, 
b.  Worker  Productivity 

Worker  productivity  also  Influences  mission 
capability  rates.  In  order  for  productivity  to 
Increase,  workers  must  be  freed  from  non-essential 
tasks  so  that  they  are  able  to  spend  as  much  of  their 
time  as  possible  directly  on  aircraft  repairs. 
NALCOMIS/OMA,  therefore,  must  provide  users  with  fast 
and  easy  access  to  NALCOMIS  functions,  allow  for  fast 
and  accurate  data  entry,  and  check  these  entries  for 
validity.  NALCOMIS  must  provide  these  services  in  a 
way  which  Is  better  than  the  current  manual  system  or 
significant  Improvements  In  mission  capability  are 
unlikely  to  occur  as  a  result. 

The  computerized,  on-line  VIDS/MAF  provided 
for  by  NALCOMIS/OMA  can  help  Improve  worker  productiv¬ 
ity  by  offering  several  advantages  over  the  current 
manual  system: 

1)  Less  lost  paperwork. 

2)  Elimination  of  the  physical  delivery  of  VIDS/MAF 

copies . 

3)  Fewer  data  entry  errors. 

4)  Automatic  verification  of  data.. 

5)  Less  handling  of  data. 
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2.  Lessons  Learned  From  Phase  II  j 

< 

Numerous  problems  encountered  by  users  of  | 

NALCOMIS  Phase  II  should  be  resolved  prior  to  further  J 

j 

NALCOMIS /OMA  development:  j 

a.  Users*  Expectations  j 

Users  must  have  a  thorough  understanding  of 

NAMP  procedures  and  the  NALCOMIS  functions  with  which 

they  will  be  dealing  in  order  to  prevent  overly  high  j 

expectations  on  the  part  of  the  users.  An  understand- 

I 

lng  of  the  NAMP  and  current  manual  procedures  Is  also 

necessary  In  the  event  that  NALCOMIS  breaks  down  and  J 

users  must  revert  to  a  manual  (paper  VIDS/MAF)  back-up 

system. 

b.  Ease  of  Use 

Although  screens  and  conversations  have 
been  designed  with  ease  of  use  In  mind,  learning  to  use 
NALCOMIS  may  present  a  problem  for  new  users.  Even 
after  gaining  experience  with  NALCOMIS/OMA.  some  users 
may  continue  using  paper  forms  In  lieu  of  some  NALCOMIS 
menus  and  screens. 

c.  The  Automated  VIDS/MAF 

In  some  cases  NALCOMIS  will  require  more 
effort  than  the  current  manual  system.  With  an 
automated  MAF.  It  Is  necessary  to  take  a  certain  amount 
of  time  to  log  onto  the  system  and  go  through  the 
appropriate  conversations.  Each  user  must  perform 


these  logon  procedures  prior  to  using  NALCOMIS,  even 
for  very  simple  tasks.  A  queuing  problem  can  poten¬ 
tially  develop  any  time  more  than  one  user  within  the 
work  center  needs  access  to  the  system  at  the  same 
time. 

It  may  be  more  difficult  to  understand  the 
overall  maintenance  situation  from  NALCOMIS  screen 
outputs  than  Is  currently  done  with  the  VIDS  board. 
Maintenance  managers  may  feel  much  less  confidence  In 
their  abilities  without  the  presence  of  a  VIDS  board  In 
maintenance  control . 

More  personnel  may  be  required  In  Mainte¬ 
nance  Control  under  NALCOMIS/OMA  than  with  the  current 
manual  system.  Besides  the  extra  effort  required  to 
see  the  overall  maintenance  picture,  one  terminal 
within  Maintenance  Control  may  prove  to  be  Inadequate. 
Since  the  maintenance  effort  Is  so  dependent  on  the 
VIDS  board  for  decision  making,  as  many  as  three 
terminals  might  be  required  to  allow  Maintenance 
Control  to  keep  up  with  all  of  the  Information  neces¬ 
sary  to  coordinate  the  maintenance  effort, 
d.  Ignoring  the  System 

On  occasion,  some  personnel  may  attempt  to 
bypass,  or  Intentionally  Ignore,  NALCOMIS.  Heavy 
schedule  pressures,  compounded  by  the  fact  that 
NALCOMIS  may,  under  some  circumstances,  be  slow  or 
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momentarily  inaccessible,  could  mean  that  simple 
discrepancies  will  not  be  written  up  at  all.  If 
NALCOMIS  Is  judged  by  users  as  being  slower  or  more 
trouble  than  the  current  paper  system  and,  as  a  result. 
Is  Ignored  by  maintenance  personnel,  safety  may  be 
Jeopardized. 

e.  Security 

User  passwords  could  freely  be  handed  from 
one  person  to  another  for  the  sake  of  convenience. 

Lists  of  passwords  (e.g.,  a  work  center  supervisor  In 
possession  of  the  passwords  of  Collateral  Duty  Inspec¬ 
tors  and  Quality  Assurance  Representatives)  could  be 
used  In  order  to  quickly  and  conveniently  sign  off  a 
MAF.  Such  practices  could  make  It  very  difficult  to 
prove  or  disprove  claims  by  an  Individual  that  his 
password  has  been  compromised. 

f.  Purging  of  Data 

Retrieving  data  that  has  already  been 
purged  from  the  squadron's  NALCOMIS  data  base  may  be  a 
very  time-consuming  process.  Those  needing  to  keep 
Information  for  historical  purposes,  such  as  Quality 
Assurance,  will  probably  keep  printouts  and  continue 
using  manual  Information  storage  and  retrieval  methods. 

g.  Management  Support 

NALCOMIS/OMA  may  not  readily  provide 
managers  with  the  Information  needed  to  make  day-to-day 


decisions.  NALCOMIS/OMA  could  be  streamlined  in  some 
functional  areas  In  order  to  make  rooa  for  more 
management  Information. 

The  concepts  which  are  encompassed  In 
current  plans  for  NALCOMIS/OMA  are  seen  by  present  and 
potential  future  users  as  being  both  necessary  and 
highly  desirable.  Automation  and  the  resulting  changes 
In  current  procedures  are  viewed  as  worth  the  effort. 
NALCOMIS  Phase  II  users  and  squadron  maintenance 
managers  who  were  Interviewed  for  this  thesis  felt  that 
an  automated  maintenance  system  Is  long  overdue.  There 
Is  no  reason  to  expect  that  NALCOMIS/OMA  cannot  be 
successfully  Introduced  to  the  fleet  once  these  and 
other  critical  management  Issues  are  adequately 
resolved. 

B.  RECOMMENDATIONS 

Based  on  the  research  conducted  In  the  course  of 
this  thesis,  the  following  recommendations  for  Improve¬ 
ments  to  NALCOMIS/OMA  and  the  need  for  further  research 
are  proposed: 

1.  straM^  lnlng  NALCOMIS/OMA 

The  functions  of  NALCOMIS/OMA  should  be  limited 
to  those  which  will  contribute  toward  Improved  mission 
capability.  First,  NALCOMIS/OMA  should  provide  better 
support  to  local  decision  makers  by  allowing  the 
creation  of  customized  reports  and  screens.  Also, 


special  emphasis  should  be  placed  on  ensuring  the 
successful  Implementation  of  the  interface  with  the 
Supply  Support  Center.  Secondly,  NALCOMIS/OMA  should 
reduce  the  time  that  workers  spend  on  non-essential 
tasks.  The  time  required  for  users  to  access 
NALCOMIS/OMA  should  be  minimized.  An  attempt  should 
also  be  made  to  reduce  the  number  of  screens  and 
conversations  required  to  obtain  routine  Information. 

2.  Reporting  Up  the  Chain  of  Cn«B»nd 

Consideration  should  be  given  to  allowing 

squadron  Maintenance  Officers  the  option  of  screening, 
and  subsequently  editing  Information  being  reported  up 
the  chain  of  command.  As  discussed  In  Chapter  III, 
automatic  reporting  of  data  could  result  In  several 
undesirable  conditions. 

3.  Low-Level  User  Involvement 

Further  development  of  NALCOMIS/OMA  should 
Include  more  low-level  user  Involvement.  Without  the 
acceptance  of  low-level  management,  NALCOMIS  won't  be 
likely  to  achieve  the  degree  of  success  that  top 
management  Intends. 

4.  Learning  From  Phase  II 

Comprehensive  documentation  of  NALCOMIS  Phase 


II  development,  testing,  and  user  problems  should  be 
kept  and  applied  to  further  NALCOMIS/OMA  development  to 
ensure  that  common  problems  are  dealt  with  In  a  timely 


fashion.  While  some  parallel  development  of  Phases  II 
and  III  has  taken  place,  lessons  learned  from  Phase  II 
should  be  promptly  applied  to  NALCOMIS/OMA. 

5 .  OMA-IMA  Functional  Relationship 

Further  study  should  be  conducted  to  determine 
which  functions  of  NALCOMIS  Phase  II  are  appropriate 
for  the  OKA .  While  many  of  the  functions  of  Phase  II 
appear  to  be  suitable  for  Implementation  at  the  OKA, 
certain  environmental  differences  exist  between  the  IMA 
and  the  OMA.  For  example,  schedule  pressures  and 
operational  commitments  at  the  OKA  create  considerably 
different  requirements  for  Information. 

6.  Local.  Informal  OMA  Functions 

Further  study  of  local.  Informal  OMA  functions 
and  processes  should  be  conducted  In  order  to  assess 
their  potential  Impacts  on  NALCOMIS/OMA.  For  example, 
the  Intercom  system  used  by  squadron  maintenance 
departments  provides  maintenance  managers  with  fast, 
real-time  information.  If  the  Intercom  system  provides 
Information  faster  than  some  portion  of  NALCOMIS/OMA, 
then  maintenance  personnel  will  continue  to  use  the 
Intercom  instead  of  that  portion  of  NALCOMIS. 
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APPENDIX  A:  ACRONYMS 


ADB  -  Aircraft  Discrepancy  Book 


ADP  -  Automated  Data  Processing 


AIMD  -  Aircraft  Intermediate  Maintenance  Department 


AMO  -  Assistant  Maintenance  Officer 


AV-3M  -  Aviation  Maintenance  and  Material  Management 
System 


AWM  -  Awaiting  Maintenance 


AWP  -  Awaiting  Parts 


CDI  -  Collateral  Duty  Inspector 


COBOL  -  Common  Business  Oriented  Language 


CPO  -  Chief  Petty  Officer 


CPS  -  Characters  Per  Second 


DOD  -  Department  of  Defense 


DPS  -  Distributed  Processing  System 


DSF  -  Data  Services  Facility 


HIS  -  Honeywell  Information  System 


IMA  -  Intermediate  Maintenance  Activity 


IMRL  -  Individual  Material  Readiness  List 


JCN  -  Job  Control  Number 


LAMPS  -  Light  Airborne  Multi-Purpose  Systems 


LPM  -  Lines  Per  Minute 


MAF  -  Maintenance  Action  Form 


MAG  -  Marine  Corps  Aircraft  Group 


MB  -  Megabyte 
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MCAS  -  Marine  Corps  Air  Station 

MCPO  -  Blaster  Chief  Petty  Officer 

BIOS  -  Maintenance  Data  Report 

MIS  -  Management  Information  System 

MMCO  -  Maintenance /Material  Control  Officer 

BIMP  -  Monthly  Maintenance  Plan 

BtV  -  Megaword 

NALCOMIS  -  Naval  Aviation  Logistics  Command  Management 
Information  System 

NALCOMIS/ 0B1A  -  Naval  Aviation  Logistics  Command 

Management  Information  System  for 
Organizational  Maintenance  Activities 

NAMP  -  Naval  Aviation  Blalntenance  Program 

NAVMASSO  -  Navy  Blanagement  Systems  Support  Office 

NDS  -  NALCOMIS  for  Detachments  Subsystem 

NMCS  -  Not  Mission  Capable  Supply 

NSBKM  -  NALCOMIS  Sepal  rabies  Blanagement  Module 

OMA  -  Organizational  Maintenance  Activity 

OPTAR  -  Operating  Target 

PMA  -  Project  Manager  Air 

PMCS  -  Partial  Mission  Capable  Supply 

OA  -  Quality  Assurance 

QA/A  -  Quality  Assurance/Analysis 

QAS  -  Quality  Assurance  Representative 

SMQ  -  Special  Maintenance  Qualification 

SNAP  -  Shipboard  Non-Tactlcal  ADP  Program 

SSC  -  Supply  Support  Center 

VERTREP  -  Vertical  Replenishment 


VIDS  -  Visual  Information  Display  System 


VIDS/MAF  -  Visual  Information  Display 

System/Maintenance  Action  Form 
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